[csharp-netcore] Make Blazor Webassembly compatible

[Blackclaws]

This is a first step that in general makes the API Client compatible with Blazor Webassembly applications. I'll add some more detailed instructions later but it does work already out of the box. Performance improvements as well as size improvements are something that is definitely desirable in that scenario but that can come later.

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master, 5.1.x, 6.0.x
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[wing328]

Shall we log a warning message or use other channels to notify the users/developers? It seems like the exception is now discarded silently.

[Blackclaws]

A good question and one I've also asked myself. The issue is that PlatformNotSupported is a very specific exception that I think is only thrown on Blazor WASM right now (as its running in Browser).

If we start logging this now this will clutter up the console log of anyone using the generated code for any api call on that platform. We could introduce a logging level cli switch for generating code that would introduce log messages here and at other places throughout the code. That might be an interesting addition anyway.

[wing328]

If we start logging this now this will clutter up the console log of anyone using the generated code for any api call on that platform

What about we start with this and revise the logging strategy later if users complain about it?

I still prefer over-communication to the users/developers to start with because I'd bad experiences dealing with errors being silent before.

[wing328]

Let's go with what you've so far to start with. We can always improve later with another PR.

[wing328]

cc @mandrean (2017/08) @frankyjuang (2019/09) @shibayan (2020/02) @Blackclaws (2021/03)