Make ILTypeDef super type calculation lazy

[DedSec256]

By analogy with issues from previous PRs (#17392, #16168) which added ways to pass lazy calculation of custom attributes and interfaces, ILTypeDef constructor (public API) lacks the ability to pass lazy computation of a base type. Right now, it is necessary to read the base type when creating ILTypeDef only to calculate ILTypeDefKind using the name of the base type, which seems redundant.

Therefore, this PR proposes:

• Ability to pass lazy computation of a base type to ILTypeDef constructor
• Logic to compute ILTypeDefKind using lightweight base type name lookup without fully reading base type
• Additional constructor for ILTypeDef that does not require lazy evaluation and automatically evaluates ILTypeDefKind
• Combining ILTypeDefKind with ILTypeDefAdditionalFlags into a single enum (in future prs, I will try to combine it with TypeAttributes and get rid of another redundant field in ILTypeDef)

Changes from this PR also show a slight performance increase in benchmarks (similar analysis of the ReSharper.FSharp.Psi.Services project as in previous PRs), although this is not the main reason for creating this PR

Method	Mean	Error	StdDev	Gen0	Gen1	Gen2	Allocated
TypeCheckFile - Before	6.946 s	0.0854 s	0.0799 s	32000.0000	14000.0000	5000.0000	6.88 GB
TypeCheckFile - After	6.747 s	0.0693 s	0.0648 s	31000.0000	13000.0000	5000.0000	6.86 GB

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/9.0.200.md

[KevinRansom]

The deletion of ILTypeDefKind caused quite change to the compilerservice surface area. I presume compilerservice customers won't feel the pain to badly. I wonder if we should consider locking it down to no breaking changes. However, that is probably a discussion for another time.

[auduchinok]

The deletion of ILTypeDefKind caused quite change to the compilerservice surface area. I presume compilerservice customers won't feel the pain to badly.

@KevinRansom Thanks for bringing this up, it's indeed important that we make things easier to FCS users. As it has been over the last few years, usually the changes improve things enough to justify the costs of updating things 🙂

AFAIK, the only FCS client that currently works with these IL types directly is Rider, and this change improves the things for us, so we're happy to update the changed types usages.