Give errors on calls to client-only methods from server-side

[Jand42]

WebSharper.JavaScript.Interop.X should be considered client-only, as are all methods that has only this as body and all WIG methods. (Recursive exploration of further client-only methods are probably not a good idea, as they may call client-only code conditonally.)

Give an error when one of these are called from non-JavaScript annotated code.

[Jand42]

This analyzer could also treat IsClient specially as in #730. Client-only calls in a false path would give a compile-time error.

[Jand42]

@granicz @Jooseppi12 Additional ideas:

• The JavaScript attribute now has a constructor overload that takes a JavaScriptOptions enum for some rare use cases (optimized interface proxying in WS.Main, ignoring type lookup on defaultof). We can add a new flag here that also marks a module/class/member as client-only, it would look like: [<JavaScript(JavaScriptOptions.ClientOnly>]
• As analyzing all calls in server-side+shared code for client-only calls to give errors takes some extra compilation time, we should make this feature optional too. As I don't think the performance hit could be substantial (linear checks only), my suggestion is to make it opt-out, in wsconfig.json: clientOnlyErrors: false while default is true. Equivalent project file property would be <WebSharperClientOnlyErrors>
• WIG should just mark whole assembly ClientOnly by default for simplicity, WIG dlls have no .NET implementations.
• We can still check for if method body is a single call to WebSharper.JavaScript.Interop.X<_> as in original idea and then mark as ClientOnly implicitly, makes updating WS core libraries for this feature much faster.