Reduce noisy C# compilation errors

[RReverser]

Description of Changes

When source generator processes code that misuses SpacetimeDB APIs, has wrong signatures, uses types incompatible with BSATN etc, it reports diagnostics but still emits new source code. In some cases, this improves autocomplete and diagnostics, since types and methods are still there even while code is not 100% valid yet, but in other cases the output code is so broken that .NET attempting to compile it will only produce even more noisy errors, which drown out the custom actionable diagnostic we emitted earlier in the pipeline.

This PR fixes couple of such cases by either fixing up or skipping particularly problematic entries during the codegen phase.

You can see the difference in the crates/bindings-csharp/Codegen.Tests/fixtures/diag/snapshots/ExtraCompilationErrors.verified.txt snapshot, which captures all the .NET
compilation errors that didn't come from our own source generator - there is a lot less noise after this PR.

API and ABI breaking changes

If this is an API or ABI breaking change, please apply the
corresponding GitHub label.

Expected complexity level and risk

1
How complicated do you think these changes are? Grade on a scale from 1 to 5,
where 1 is a trivial change, and 5 is a deep-reaching and complex change.

This complexity rating applies not only to the complexity apparent in the diff,
but also to its interactions with existing and future code.

If you answered more than a 2, explain what is complex about the PR,
and what other components it interacts with in potentially concerning ways.

Testing

dotnet test snapshot tests

[kazimuth]

This looks good, I like Unsupported<T>. My only concern is that this change might allow erroring modules to compile in unusual situations. However, this PR does a good job of having comments everywhere errors are suppressed, documenting that some other error has already been emitted. So I'm happy with this.

[RReverser]

My only concern is that this change might allow erroring modules to compile in unusual situations. However, this PR does a good job of having comments everywhere errors are suppressed, documenting that some other error has already been emitted.

Hm yeah that's a good point. FWIW the other mitigating factor is that in all those scenarios, worst that can happen is a runtime error instead of a compile one. But yeah, something to look out for if it slips through the tests.