[C#] Add support for IEnumerable<T> for Views' return types

[rekhoff]

This is the implementation to resolve #4424

Description of Changes

• Add support for IEnumerable<T> as a valid C# View return type in codegen, so view implementations can return query results without forcing ToList(). The generator now detects IEnumerable<T>, serializes it via the list serializer.
• Snapshots have been updated with a test to confirm that IEnumerable<T> rather than checking it is unsupported (which we had added when removing support during the transition away from Query<T> usage.
• Refreshes docs/examples to reflect the new supported signature.

API and ABI breaking changes

No breaking changes. This is additive support for an existing .NET interface.

Expected complexity level and risk

2 - Low

Testing

• Rebuilt CLI locally, ran regression tests, and dotnet tests in C# module bindings.
• Tested updated docs code snippets to ensure they resolve in an IDE and publish.

[joshua-spacetime]

Do both of these options implement IEnumerable? If so, we could just assert IEnumerable or IQuery.

[rekhoff]

No, neither actually implement IEnumerable themselves. Technically this is just validating that these are the BSATN representations. IQuery<T> also does not implement IEnumerable itself.
But if I understand the question, since we already check a bool for ReturnsQuery and ReturnsEnumerable, are you saying why don't we utilize that information in the test?
We could do that, but we'd miss checking for T? (the Option type return).
So I'd need to check something like

bool isOption =
    ReturnType.BSATNName.Contains("SpacetimeDB.BSATN.ValueOption")
    || ReturnType.BSATNName.Contains("SpacetimeDB.BSATN.RefOption");

And then could change the check to something like:

if (!ReturnsQuery && !ReturnsEnumerable && !ReturnsOption)
{
    diag.Report(ErrorDescriptor.ViewInvalidReturn, methodSyntax);
}

If you'd prefer, and find this to be more clear.

[joshua-spacetime]

Yeah let's do that. I was hoping that T? would be IEnumerable too, but we can at least have IEnumerable subsume List<T> to avoid a redundant check.

[rekhoff]

Requested updates made

[joshua-spacetime]

Do we still need this check or does IEnumerable make this one obsolete?

[rekhoff]

Yes, we still need it, because the List<T> is a valid return type. If we don't have that as a valid return type, any places where List<T> is returned, it will report that as an error. Even if there is a conversion between List<T> and IEnumerable, we accept both at this point.