Split identifier calculation from code context and bind marshallers to the code context

[jkoritzinsky]

Split out GetIdentifier and CodeEmitOptions from the StubCodeContext into a StubIdentifierContext.

Use only TypePositionInfo and StubCodeContext to resolve to generator instances and include StubCodeContext in the information bound into a bound marshaller.

Use StubIdentifierContext during actual codegen to provide identifiers for TypePositionInfo instances.

Construct the TypePositionInfo correctly from the start so we never have to rebind and remove the Rebind method.

Keep count info structured longer (required as part of the above changes) and fix a latent bug.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

[jtschuster]

I'm a bit confused why we can't store the StubIdentifierContext information in the IBoundMarshallingGenerator objects (aside from the stage information). Why do we need to pass it down through the GenerateX methods? Do we not know at generator resolution / binding time whether it will be the DefaultIdentifierContext or the LinearCollectionElementIdentifierContext?

[jkoritzinsky]

We can't store the StubIdentifierContext as we can't construct a DefaultIdentifierContext with the correct identifiers for the stub return value until we've already bound the generators. Additionally, we have some scenarios (primarily the "can we convert" analyzers) where we don't actually need identifiers at all as we aren't generating code, we're only attempting to bind generators.

[jkoritzinsky]

Additionally (until we change how we handle ownership), we have the OwnedValueContext (which is a StubIdentifierContext) as well, which we use only during code-gen in some stages (with the same TypePositionInfo and StubCodeContext), so being able to change how we use identifiers is important.

I'm also planning refactoring how we handle the fact that pointers can't be used in generics to use a custom StubIdentifierContext instead of syntax rewriting in preparation for #95882, which means we'll have another scenario where we use a separate identifier context at codegen time from bind time.

[jkoritzinsky]

/ba-g Firefox failure unrelated