Move to using the new Roslyn IIncrementalGenerator API for better in-VS performance

[jkoritzinsky]

Through some local testing, it was determined that using the ISourceGenerator V1 API for DllImportGenerator will cause the same VS performance issues as dotnet/runtime#50741. Since the source our generator generates is required at design-time, we cannot take the same resolution as dotnet/runtime#50741 or use a simple non-incrementable direct port to the V2 API with the new "Implementation" source type to avoid impacting design time builds (dotnet/roslyn#54798).

As a result, this PR moves our source generator to a more incremental design.

I've split the pipeline of the generator into a few sections:

• Checking if TFM is supported
• Finding all attributed methods
• Determining the marshalling info for parameters and return values, as well as the GeneratedDllImport attribute info
  • From this point onwards, we no longer use ISymbol-implementing types. Symbols are not equatable across compilations, so any stages where they are in the output are not cacheable between generator runs.
• Generating syntax for the stub from the marshalling info
• Adding whitespace to the syntax
  • This operation is apparently very expensive, so by caching before we do this, we can skip this expensive step when the stub doesn't change.
• Concatenating all of the stubs into one file.
• Reporting the new file and all diagnostics.

As part of this refactoring, I moved TypePositionInfo to use a new type model to represent the managed type of the parameter/return value instead of symbols due to the caching issues mentioned above.

The testing for the incremental support is an ad-hoc testing model that will be replaced when dotnet/roslyn#54832 is approved, implemented, and available.

I have validated with this branch that there is no typing lag when working in the System.Private.CoreLib solution from dotnet/runtime on a Surface Book 1 i7 (my work laptop).

[jkoritzinsky]

@sharwell I can't seem to repro the failures locally. It looks like some sort of infra issue with the CodeAnalysis.Testing package. Can you take a quick look and see if you can figure out what's going on?