(build-tools): Add command to update types

[sonalideshpandemsft]

This new flub command will be used to update the package.json types to point to the alpha/beta release as required.

This command first verifies the presence of an api-extractor.json file and subsequently examines its rollup configurations. If these configurations are present, it proceeds to update the package.json's types/typings field based on predefined conditions and flags.

The updated package.json is serialized while retaining its original formatting and then written back to the file.

flub release setPackageTypesField -g client --types alpha --json
flub release setPackageTypesField -g client --types beta --json
flub release setPackageTypesField -g client --types public --json
flub release setPackageTypesField -g client --types untrimmed --json

AB#5535

[tylerbutler]

Think about how to test this. If you factor out the main code into functions that accept a Package, then you can write tests that check that the properties are set correctly by the functions, for example.

[CraigMacomber]

How have you been testing this? Overall direction looks good, but I think the data you pass around between functions can maybe be simplified and I'm not clear exactly how this will get used in the CI. Maybe this PR is not the right one, but ultimately I want to know how and when we're going to publish alpha/beta builds. Is the whole release group considered an alpha/beta release, and that's decided when we run the release pipeline? Or are we planning to run a second pipeline that publishes alpha/beta packages? Something else?

1. How and when we're going to publish alpha/beta builds?
   Afaik, alpha/beta builds would be usually published on demand.
   cc: @CraigMacomber, looking forward to your thoughts on this questions
2. Is the whole release group considered an alpha/beta release, and that's decided when we run the release pipeline? Or are we planning to run a second pipeline that publishes alpha/beta packages?
   The entire release group is labeled as an alpha/beta release based on the chosen Release Build type (alpha/beta) when running the release pipeline.

This makes me wonder, is it possible to release a single package say @fluid-experimental/tree2 and not the entire client group?

1. For now, manually when a developer decides to make one and give it to a customer for testing. Eventually we might formalize this a bit more, but the main purpose is to be able to iterate on an API with a customer or a few customers productively (so in main, without having to semver stabilize it until after iterating a few times), and manual releases are fine for that (we need a personal relation with the customer using it to apply their feedback anyway).
2. I think doing this at the release group level makes sense. It ensures the packages being released have corresponding packages to depend on, and allows alpha apis in one package to depend on alpha apis in another, which is I think is how API-extractor assumes things works and seems like what we want (we need it for testing out APIs that span multiple packages for example)

[CraigMacomber]

I don't think you should refer to these as dtsTypes. Multiple .d.ts files being involved here is really an implementation detail of how this system you are making works with API-extractor.

I think it would make more sense to name thins (like this command, and this list) after "releaseTags" and link https://api-extractor.com/pages/tsdoc/doc_comment_syntax/#release-tags for additional docs.

Naming the command something like "selectReleaseTagToPublish" would be much more clear.

[tylerbutler]

"release" is a very overloaded term. I don't want to use it for this purpose. This work is explicitly about types only. Nothing related to what we release when, what version the release will have, etc. This tool only changes the types between "flavors" of the types.

[tylerbutler]

It also has nothing to do with "publishing," so I don't think setReleaseTagToPublish is a good choice either. Maybe setPackageTypesField?

[Josmithr]

Is this as any cast needed? Might need to explicitly type knownDtsKinds as string[]?