Quality of life improvements for use in stand-alone servers

[NoTuxNoBux]

This is a continuation of #310, as the original author is no longer interested in fixing the changes.

From the original PR:

These are more of a quality of life changes for those who use the StandAlone Server.

Changes as follows:
-Added StandAloneNetworkObjectFactory for use with StandAlone Server
-Added Float2, Float3, and Float4 as substitutes for Unity's Vector2, Vector3, and Vector4 (Color & Quaternion) for use with the StandAlone Server with operators for converting between them
-Added code generation for Non-Monobehavior NetworkObjects

I've processed some of the feedback on the pull request as well:

• Interpolation using the new float types is now supported.
• ToString overrides were added for the new types for easy debugging.
• .NET's System.Numeric types are now used instead of new custom types.
• A Unity import breaking stand-alone use was removed from the generated network objects.
• UnityNear was consolidated with Near as the former already falls back to the latter, but the former doesn't work in stand-alone projects as it depends on Unity, and it was also used in network objects, which was also updated.
• Changes to StandAloneObjectMapper are now part of ObjectMapper as these new types don't conflict with the existing types and this prevents new users from being confused, as they would need to call StandAloneObjectMapper.Instance.UseAsDefault(); to get them recognized in network objects.

Open questions:

• ~Do we switch from FloatX to System.Numerics.VectorX, as suggested by @phalasz?~ Done.
• Since conversion exists between the new types and Unity's types, would it be a good idea to drop the Unity types entirely from Forge? This would be less confusing for newcomers, as there are no apparent duplicate types, it makes it harder to accidentally depend on Unity types, and it simplifies the code.
• The original code generates separate network objects from a separate template. This has the following problems:
  • You have to choose between stand-alone use or not. Why is this necessary? Now that StandAloneObjectMapper and UnityNear are gone, we can have a single generated version that works both stand-alone and inside Unity, though dropping the Unity types above would make be required.
  • You have to uncheck "Generate MonoBehavior" to get the stand-alone version. This is not only confusing - as it's not clear that you need to uncheck it to get the stand-alone versions -, but you may also want to keep the monobehaviors anyway for use in your Unity project, as they are just a convenience wrapper around the network objects that aren't necessary in the stand-alone server and that you can just leave out.

[NoTuxNoBux]

Something that I also realized just now: currently I'm not sharing the behaviors with my stand-alone server - as they depend on Unity things and I don't need them -, but the behaviors contain the codes for the generated RPCs, which I then also lose.

I can call RPCs through their name, but that's already been deprecated. Thinking about this some more: wouldn't it be more logical if we move the constants to the generated network object instead of the behavior? I'm talking specifically about these lines:

public const byte RPC_YOUR_RPC_1 = 0 + 5;
public const byte RPC_YOUR_RPC_2 = 1 + 5;

This would fix the sharing problem, and it would also make more sense, since you invoke the RPCs on the network object anyway, and not the behavior - the behavior also doesn't use them for anything else.

Another option would be to generate a separate file (enum?) with these RPCs in, that could then be shared again.

The registration of the RPCs itself is another thing that would be interesting to move to the network object instead, as now the stand-alone server needs to manually register the same RPCs (in the same order), as it cannot reuse the behavior. They could fire events from the network object that are caught by the behavior in order to call the methods you have to overload.

[NoTuxNoBux]

I updated the pull request to use .NET's System.Numeric types instead of custom types as suggested by @phalasz. This reduces the code Forge needs to maintain. I've also bound Quaternion next to Vector4, which uses Slerp instead of Lerp to fix interpolation issues.

The only downside so far is that System.Numeric is not a partial struct, so implicit operators to convert to Unity variants is no longer possible. I've introduced explicit extension methods to do this, instead.

[NFMynster]

Hello @MrWatts-Anorak, are you on the Forge discord? If so, please tag me at NFMynster#1588