Fix for several invalid versions

[mgdcvetko]

Hi, we noticed that five packages had invalid versions listed in their advisories. It's the same mistake across all advisories - version 1 is listed, while malicious packages actually published version 1.0 and never just 1.
This PR would fix this in all five OSSF published advisories, and I will also fix this in our reports in the AWS bucket.

Mentioning @rhalar for visibility.

[rhalar]

I have to bring this up again, just to make sure we're in sync with @calebbrown, and handling this correctly.

So our procedure usually is that when non-additive changes happen to an advisory, we withdraw the advisory and generate a new one, with a new ID. This generates 'extra' advisories and withdrawals, and since the OSSF doesn't handle withdrawals automatically we decided to fix up existing ones manually for these smaller scale issues. This was already done in #673

This is why there are two entries in malicious-packages-origins for RLMA-2024-03512
https://github.com/ossf/malicious-packages/blob/main/osv/malicious/pypi/admcheck/MAL-2024-4732.json#L48

@calebbrown commented that this is okay, since the 'history' is preserved #673 (comment)

But that worked because the whole bucket was reprocessed from the start last time, which I don't believe will be the case anymore?
If we plan to manually edit existing advisories now, we probably need to generate a new entry in malicious-packages-origins as well?

[calebbrown]

If an additional version is added, it might be better to publish a new updated version of the report with the correct version(s), with a higher number (or an RLUP- report).

This would be merged and add the version the report.

Removing the "1" currently must be done manually.

If you'd prefer I can update all the versions in this PR.

[calebbrown]

This PR is not entirely necessary as far as Python is concerned.

According to the version spec "1" and "1.0" refer to the exact same version of a package.