platform support documentation [skip ci]

[baentsch]

Implements results of discussion on platforms supported.

• [no] Does this PR change the input/output behaviour of a cryptographic algorithm (i.e., does it change known answer test values)? (If so, a version bump will be required from x.y.z to x.(y+1).0.)
• [no] Does this PR change the list of algorithms available -- either adding, removing, or renaming? Does this PR otherwise change an API? (If so, PRs in fully supported downstream projects dependent on these, i.e., oqs-provider and OQS-OpenSSH will also need to be ready for review and merge by the time this is merged.)

[baentsch]

Additional thought: "Tier 0" sounds a bit .... "close to negative" :), i.e., to me feels not properly denominating the "highest" tier. Also, what about platforms for which there shall be formally verified implementations available (that also should be CT & side-channel attack resistant & code-reviewed & fuzzed & .... etc.): Shouldn't those represent the highest tier? Slight disadvantage of such tier: It would have no entries right now...

[SWilson4]

Additional thought: "Tier 0" sounds a bit .... "close to negative" :), i.e., to me feels not properly denominating the "highest" tier. Also, what about platforms for which there shall be formally verified implementations available (that also should be CT & side-channel attack resistant & code-reviewed & fuzzed & .... etc.): Shouldn't those represent the highest tier? Slight disadvantage of such tier: It would have no entries right now...

What about keeping them as "Tier 1" but marking them with an asterisk? We can add extra modifiers as needed for additional tested properties. I agree that we don't want to run up against the well-ordering principle. ;)

[SWilson4]

I made one (very, very minor) suggestion to change the asterisk to a dagger, as I realized that asterisks (1) don't stand out much to a reader and (2) are used for a wide variety of other meanings in documentation. Plus we already use a dagger in the README.