Improved F# Support

Is your feature request related to a problem? Please describe.
Currently Stride does not have good F# support. It is possible to have an F# project as a dependency and if the components already exist on an entity they will be deserialized correctly, but the components do not show up in the add components menu. The other option currently possible is to create a C# facade over your F# type to have the component show up but this is cumbersome and requires you to create both a F# type and a C# type. Neither of those options provide a nice workflow for working with F#.

Describe the solution you'd like
It would be very nice if F# would be a first class citizen within Stride but for now better partial support would already be nice. I've been experimenting with the codebase a bit and was able to have F# projects somewhat working within the gamestudio however my changes feel quite hacky. https://github.com/Zeroto/stride/commit/ef36f9811789c10ab92ecb6c6424c08b00e3d1a6

With these changes the projects show up in the gamestudio and the assemblies will be reloaded when they are built outside of stride. The components will show up in the add components menu and can be used like any other component. The problems with this current solution is that it doesn't automatically rebuild after a source file change. It always requires a manual rebuild(or use something like dotnet watch). It also does not show the code files in the asset view. Other than that it does seem to work fairly well, but I have not done any in-depth testing or extensive use of both C# projects and F# projects together to see if these changes cause any problems.

A few of the problems with adding F# support to the current codebase are

• Both Roslyn and Microsoft.CodeAnalysis.MSBuild are used in multiple places and are not abstracted away. If there is an abstraction layer in between then it would possible to use Roslyn for C# projects and FSharp.Compiler.Services for the F# projects.
• There are a few checks in the codebase on the string literal "csproj". This can be solved in the same way by having those checks point to the layer in between.

Going forward
I can create a pull-request of the changes made so far so F# support is at least partially working. For better support in the future we should probably add an abstraction layer in between as mentioned above.

Review the referenced experimental commit first to understand the current partial approach to F# projects, assembly reloads, component discovery, and code-file display. Then map the existing Roslyn and MSBuild integrations and the literal "csproj" checks. Done means F# projects support the stated workflow without breaking mixed C# and F# projects, including automatic rebuilds and code files in the asset view.