Fix as type implementation

[CasperWA]

Closes #56.

If as type is supplied it is understood that the domain+path constitutes the complete URL to be tested.
Hence, only a single validation will be run, and the parameters all versioned paths and validate unversioned path have no meaning and will be ignored.
This means as type take precedence, which is what I would expect.

Possibly add:

• Extend README with the internal precedence of parameters.

[CasperWA]

It seems to me like there's an issue with the validator when using the --as-type parameter: CI running with verbosity 2.

Edit: Now also with verbosity 3 getting DEBUG messages as well.

[CasperWA]

It looks like the validator is running fine, but then either doesn't set valid to True or another issue presents itself. It also doesn't call print_summary() before returning, but I wouldn't think that that would matter?

[CasperWA]

Hmm, I tried it locally, and the return code is 0, so I'm not completely sure what's going on here.

[CasperWA]

I found the reason for the action to exit with a non-zero code.
In Bash, if a negative check is done, and it's not true, the last pipestatus is non-zero. In order to ensure a "correct" pipestatus and
script exit code, an else clause can be added with a "pass" statement, in the form of a colon (:).

However, this created some issues with the exit code to be reported in entrypoint.sh. Instead, I have now moved the as type validator run to a later point, which should ensure the correct exit code is always reported, and there's no confusion concerning if/else tests affecting the exit code through pipestatus.

[CasperWA]

Note, currently I'm using a special branch of the optimade package for the as type CI test. Materials-Consortia/optimade-python-tools#700 needs to be merged and a new release should be made of the optimade package, before this PR can be merged.

[CasperWA]

@ml-evs ready for review

[ml-evs]

LGTM!