Remove fuzzy matching of malformed LIDVIDS

[alexdunnjpl]

Checked for duplicates

Yes - I've already checked

🐛 Describe the bug

Currently, registry-api will resolve some:product::, some:product::1 and some:product::1. to the latest LIDVID for LID some:product.

This is undesirable and support should be removed.

🕵️ Expected behavior

I expect malformed LIDVIDs to throw a 404 in all cases

📜 To Reproduce

1. Spin up registry profile `int-registry-batch-loader`
2. `curl --get 'http://localhost:8080/collections/urn:nasa:pds:insight_rad:data_derived::' | json_pp`
3. Observe successful return of v7.0 for that product

🖥 Environment Info

- Version of this software [e.g. vX.Y.Z]
- Operating System: [e.g. MacOSX with Docker Desktop vX.Y]
...

📚 Version of Software Used

No response

🩺 Test Data / Additional context

No response

🦄 Related requirements

🦄 #xyz

⚙️ Engineering Details

The key here is to remove the fuzzy-matching from PdsProductIdentifier.fromString() - if the argument contains a LID/VID separator and cannot be parsed to a valid LIDVID, it should throw a parsing error rather than falling back to extracting the LID and returning a PdsLid

[alexdunnjpl]

Will require adjustment of swagger documentation - currently shows:

syntax: lidvid or lid behavior (lid): returns one or more items whose lid matches this lid exactly. If the endpoint ends with the identifier or /latest then a signle result is returned and it is the highest version. If the endpoint ends with /all then all versions of the lid are returned. behavior (lidvid): returns one and only one item whose lidvid matches this lidvid exactly. note: the current lid/lidvid resolution will match all the lids that start with lid. In other words, it acts like a glob of foobar*. It behavesn this way from first character to the last note: simple sorting of the lidvid is being done to select the latest from the end of the list. However, the versions 1.0, 2.0, and 13.0 will sort to 1.0, 13.0, and 2.0 so the end of the list may not be the latest.