Sort the public API tracking files, with a script that keeps them that way

[mgravell]

Adds eng/public-api.py and runs it. The diff is large but the content is unchanged - verified as a pure reorder, see below.

Previously pushed straight to main as 213f3c3 and reverted in 17e16f1: a 3000-line reorder that conflicts with open PRs wants review first, whatever the mechanical verification says. Nothing is wrong with the content.

Why a script

The analyzer does not care about order and its code fix appends, so these files accrete in whatever order entries were added and drift out of any order they are put into. RESPite's 236-line shipped file was unsorted too, so this is general drift rather than one neglected file - nothing maintains order between runs. The script is what does, run at a moment somebody is already editing them.

eng/public-api.py              # sort in place, promote nothing  (default)
eng/public-api.py --promote    # the release step: fold unshipped into shipped, and sort
eng/public-api.py --check      # write nothing; exit 1 if anything is unsorted  (for CI)

Promotion is opt-in on purpose. "Shipped" means released and frozen, so folding unshipped in mid-cycle would freeze API that has not shipped and then cannot change without it looking like a break. Promotion belongs to the release: ship the package, then promote. This PR runs with no --promote, since unshipped is empty after 3.2.15 - so it is purely the sort.

The sort key is the point

It strips the modifier (and any [SERxxx] annotation) rather than sorting the raw line, so a type's surface stays in one block. Sorting raw groups by modifier instead:

	RedisValue.* (68 entries)	ConfigurationOptions.* (117)
before	7 blocks	10 blocks
sorting the raw line	4 blocks	4 blocks
this	1 block	1 block

A 3000-line reorder that still cannot show a type in one place would not be worth doing.

Verification

• Pure reorder: identical entry multiset and identical entry counts in all three files, before and after. Checked by hashing the sorted content on each side rather than by reading the diff.
• Clean full solution build, and a /p:RunAnalyzers=true build of the library - which is what actually exercises RS0016/RS0017 on every target framework, since analyzers otherwise run on one TFM only.
• Idempotent: re-running reports "nothing to do".
• Blank lines are dropped as part of sorting; there were two stray ones mid-file.

Cost worth weighing before merging

This conflicts with the open PRs that touch PublicAPI.Shipped.txt - #2107, #2221, #2547, #2838 (which appends 132 lines), #2959, #3125. Each resolves by re-adding its entries and re-running the script, but that is real work for whoever owns them, and some are old enough that a conflict may finish them off.

If that is too disruptive now, the alternative moment is the v4 break, when those branches need rebasing anyway and the churn is already priced in. The script is useful either way.

Not included

A CI step running --check. Without one this will drift again, but it is a separate decision - say the word and it is one line in the workflow.