Restructure C# SpacetimeDB runtime

[RReverser]

Description of Changes

This is a large refactor moving things around to different namespaces and utils. I meant to do this for a while, but it became particularly urgent as we're moving towards API stability.

This PR has 3 goals:

1. Simplify usings that users need to work on C# modules - now using SpacetimeDB; is all you need, without separate using SpacetimeDB.Module; and using static SpacetimeDB.Runtime;.
2. Split out and "hide" private APIs that are public only because they're used in the code emitted by codegen, but are not meant to be called by users and are not guaranteed to be stable. Before this PR, they lived in the abovementioned SpacetimeDB.Module namespace and SpacetimeDB.Runtime static class alongside real public APIs, but after this PR they're all consolidated under the SpacetimeDB.Internal namespace. This should prevent them from appearing in IDE autocomplete and make it clear they're not meant for public use.
3. Reuse SpacetimeDB.Address and SpacetimeDB.Identity between client and module SDKs. Before this PR, they were already very similar, but couldn't be reused because they lived under SpacetimeDB.Runtime class in the server-side API and under SpacetimeDB namespace in the client-side API. After this PR, they both live in the SpacetimeDB namespace in the BSATN.Runtime package which is shared between the SDKs. I've also converted them to records to simplify equality operations, added a base helper they both inherit from, as well as added some extra checks - length check + conversion to record to prevent null byte[] contents (which are too easy to get with structs but not with class or record).

Closes #1454.

API and ABI breaking changes

Very much so.

Expected complexity level and risk

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.

3 - I caught a lot of issues via both dotnet test and the SDK tests, but this is a lot of renaming and minor API changes, so it's still possible that something slipped by and the codegen references APIs which are not there anymore.

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

Describe any testing you've done, and any testing you'd like your reviewers to do,
so that you're confident that all the changes work as expected!

• dotnet test for Roslyn shapshots + extended it to make sure the output can be compiled successfully.
• SDK C# tests.
• Would appreciate reviewers playing with creating a new project, adding bunch of types / tables and checking that all works as expected.

[bfops]

@RReverser The description SGTM! Do you have recommendations for how to review the diff? How much of the added/removed code is just moved around vs genuinely changed? At first glance it seems a bit overwhelming.

[RReverser]

Almost all of the changes are genuine move around / rename / splitting out into helpers from a functional point of view.

From functional pov the only few differences that I can think of are:

• Change to the usings / lifting things to the top SpacetimeDB namespace, as the main goal of this PR.
• Making Identity and Address into records,so now users have to instantiate them via new() - previously they were structs, and compiler was happy to silently leave them with default null contents which can lead to some bad errors down the line.
• A drive by fix to iter_advance in RawBindings - it had a missing attribute that was commented out in the recent recv style ABI PR and my IDE was complaining about it. Users don't have to do anything about this one.
• Hiding the error code field from the base STDB Exception class. I don't think we want to expose it for unknown errors - it's still part of the message - so this is technically a part of the "making things private" goal.

I could split this up into a few smaller PRs, but after the experience with doing that for the previous refactor to share BSATN with the client C# SDK, having lots of small isolated PRs drags the entire review out for months. And this is not even the last refactor I want to do, there is one final one for the Codegen package as well (that one is lower priority because it would not be a breaking user-visible change)...

If you'd prefer it, I can still give it a go, but personally I'd say instead of reviewing the entire diff, just look at 1) changes to the Roslyn generated code, you can find it in Codegen.Tests/snapshots and 2) changes to user code like sdk-test-cs/Lib.cs and such.

If those look reasonable and if you can init + publish + generate client code from a C# module without issues, it should be fine.

[RReverser]

I completely rewrote Git history of this PR, each individual commit is now formatted, passes tests, and does one thing at a time with clear description.

It's a silly amount of work for something that will be squashed anyway, but should make it much easier to review on commit-per-commit basis compared to the previous mess.

[kazimuth]

Oh shoot, I forgot to post these. In general this looks good.

[kazimuth]

It turns out that review above had lost some comments so I've re-reviewed. I really don't have many comments though because this has been broken apart into commits so nicely, it generally makes sense and is clear.

[bfops]

Moving this back to 0.11 since it's blocking some 0.11 PRs

[kazimuth]

👍