[api-extractor] Introduce sort modifier to api extractor and dts rollup to avoid spurious reports between builds

[ajithAPER]

Summary Fixed https://github.com/microsoft/rushstack/issues/1958

Details API reports and DTS rollouts generated show signs of spurious inferred union types between incremental build. This implementation simply introduces a sort modifier to sort all union type in DTS rollups and API reports.

How was it tested Tested against reports within the repository generated automatically.

[ajithAPER]

This pull request cleans up the additional changes noted in https://github.com/microsoft/rushstack/pull/3698 and reintriduces the original change.

[iclanton]

As mentioned in the original issue, it would be nice to preserve the order of elements in explicitly defined union types and only apply the sorting to inferred types. It looks like this change sorts all union types. How difficult would it be to only sort inferred types? If it's too difficult to do that, can this be behind a configuration option?

Imagine you have a type that looks like this in source:

type DigitAsWord = 'zero' | 'one' | 'two' | 'three' | 'four' | 'five' | 'six' | 'seven' | 'eight' | 'nine';

where the constituents of the type have a natural order. If they're always sorted, this type will look like this in the API report:

type DigitAsWord = 'eight' | 'five' | 'four' | 'nine' | 'one' | 'seven' | 'six' | 'two' | 'zero';

which is harder to review for correctness. Did you notice that 'three' is missing from between 'six' and 'two' in the code snippet above? That would've been much easier to catch if the elements were in the same order as the source code.