core: Add custom version strings

[Dinnerbone]

This overrides $version/Capabilities.version to a custom string, if set.

Available through:

• Desktop CLI as --custom-player-version <CUSTOM_PLAYER_VERSION>
• Desktop UI
• Bundles as custom_version_string
• Web load options as customPlayerVersionString

This also changes AVM1 $version/System.capabilities.version to use the same logic as AVM2, where it will report WIN instead of LNX by default.

This should fix #22148

[moulins]

It seems somewhat unfortunate to have slightly different names between CLI/web/etc: couldn't CLI use --custom-player-version-string and bundles custom_player_version_string instead? This will probably be a rarely-used option so I wouldn't mind sacrificing conciseness here.

[Dinnerbone]

I omitted "player" from the bundle because it's under player. "player's custom player version string" just feels too redundant.

Cli I have no string feelings on, it just felt too long.

[kjarosh]

Should this be divided into two lines? Similarly lines below

[kjarosh]

I'm still wondering if we should allow producing behaviors different than FP's. I personally liked @Lord-McSweeney's idea of (optionally) passing a 4-part version. We could also use this information to infer the u8 player version so that the user doesn't have to sync those two. Plus we make sure that the content doesn't break unexpectedly and we don't produce unexpected behaviors that are not present in FP.

[Lord-McSweeney]

If we had a four-part player version, we could also observe API versioning that changed between, e.g. FP 10.0.0.32 and FP 10.1 without having to reparse the entire string.

Could we always store the player version as four u8s and make --player-version set it to X.0.0.0 and --custom-player-version (--player-version-full maybe?) set it to W.X.Y.Z?

[kjarosh]

We could also accept a,b,c,d as a variant of --player-version