Use same JSON encode/decode for Remoting as Sitelets

[Jand42]

Currently for calling Remote functions, WebSharper uses an older protocol: sending arguments by just calling JSON.stringify, and handling return values with a JSON.parse followed by some custom activation (the server sends the addresses of the prototypes to restore).

This is inconsistent with Sitelets JSON in what it can handle, proposal is to use the same.

This needs that client-side code is generated for RPC-s to handle the de/serialization. (#793)

Advantages

• More types will be available for RPC communication. (For example Dictionary #925)
• This will be more compatible with planned module loaders, as the client-side function for the RPC can explicitly require the types needed. (while current dynamic activation just assumes it is available)
• DateTime remoting will be consistent with how values are sent through websockets.
• Easier to add support for special values, like NaN (#918)
• RPC calls use a more readable format for request/response bodies, helping debugging.

Drawbacks

• A bit slower de/serialization of arguments and return values on both client and server, although the difference should be quite small.
• Larger generated code for web apps. This has some upside too, as described on #793, RPC-s would become easily callable from outside JS and console.

Extra considerations

• The Name attribute should now affect Remote functions, determining the name/address of the client-side generated function.

[Tarmil]

Another consideration: the "RPC-style" serialization format is also used to store Web.Control data in the <meta> tag. If we change RPC serialization, we should probably change that as well.

[Jand42]

Remaining pieces to fix:

• subclass handling (deserializers would try parse as subclasses first then fall back to base class, this is what we have for C# routing too)
• field renames (CompiledName attribute or discriminating base/subclass fields)