Add compat mode option to AzureClient and TinyliciousClient

[ChumpChief]

AB#7966

Based on @vladsud 's #20283 , this is a draft of API surface to toggle 1.x vs. 2.x compat mode.

Note that this feature's goal is to ensure compatible upgrade from 1.x to 2.x because the default settings don't allow for that currently. It is not a generic feature flagging API; feature owners must develop a go-to-market plan for their individual features. This API is intended to be for 1->2 only, and not for future version upgrades.

Putting up as a draft PR as a preview of the surface while I experiment with the usage. ~~Re: defaults and optionality, I optimized for (in order):~~

1. ~~Folks upgrading from 1.x get a compatible experience by default~~
2. ~~Default values prefer 2.x except where required to satisfy bullet 1~~
3. ~~Easing eventual removal of the option by preferring optional over required so customers can omit the argument as much as possible except where required to satisfy bullet 1.~~

EDIT: From feedback, changing to mandatory params.

[msfluid-bot]

⯅ @fluid-example/bundle-size-tests: +424 Bytes

Metric Name	Baseline Size	Compare Size	Size Diff
aqueduct.js	453.11 KB	453.11 KB	■ No change
azureClient.js	550.36 KB	550.58 KB	⯅ +218 Bytes
connectionState.js	680 Bytes	680 Bytes	■ No change
containerRuntime.js	256.97 KB	256.97 KB	■ No change
fluidFramework.js	357 KB	357 KB	■ No change
loader.js	132.91 KB	132.91 KB	■ No change
map.js	41.43 KB	41.43 KB	■ No change
matrix.js	143.66 KB	143.66 KB	■ No change
odspClient.js	518.9 KB	519.1 KB	⯅ +206 Bytes
odspDriver.js	97.3 KB	97.3 KB	■ No change
odspPrefetchSnapshot.js	42.16 KB	42.16 KB	■ No change
sharedString.js	160.18 KB	160.18 KB	■ No change
sharedTree.js	356.98 KB	356.98 KB	■ No change
Total Size	3.19 MB	3.19 MB	⯅ +424 Bytes

---

Baseline commit: b47f044f0899961faaa4a9b1eb3d9add245be371

Generated by :no_entry_sign: dangerJS against 522b9eeda15d610dd69571f451e50f0cf2cde7e9

[ChumpChief]

Marking this ready for review - I had a chance to experiment with this and it worked as expected in a variety of scenarios.

Main downside is that when attempting to load a "2"-mode document in a true 1.x client, the errors are a little obtuse (e.g. I hit 0x122 and "Summary metadata mismatch", Vlad's tests imply 0x162 and 0x121 would also be expected). I think this is probably best served by ensuring the documentation covers the situation well.