Make the code generator aware of syscall/js and use build tags to write dual output where needed

[bradleypeabody]

Right now if you import syscall/js in your .vugu file the corresponding .go file will not build server-side. For complex UI's this is an issue. After some discussion at https://github.com/golang/go/issues/31158, this aspect of the syscall/js package is not likely to change. So the Vugu code generator should handle it.

Some basic ideas:

• The presence of syscall/js could be detected and trigger a path that outputs two files, instead of just comp-name.go it could write comp-name-server.go.
• The comp-name-server.go would have a !wasm build tag, and all offending types like js.Value could be replaced with interface{} and method bodies for such methods could be implemented with a panic (since server code should never legitimately call it).
• If the user puts a js.Value member on a struct, it could get replaced with interface{} on the server-side output. Whether this will compile properly depends of course on how the developer is using it.
• This could handle a lot of simple situations, but there definitely also needs to be a clear path of what the developer should do if this falls short. Using build tags manually should be possible and not terribly difficult.
• This behavior should be optional, but probably defaulted to on.

Another approach would be to mirror the syscall/js so it gets imported server side as something like import js "github.com/vugu/vugu/js-stub. We'd still need to have a separate file with a build tag, but it could seriously reduce the amount of weirdness required during codegen. I like this idea...

The code generator should probably look for it's "do not edit!" comment before clobbering an existing file, since someone could accidentally get burned if a subtle change add a single js.Value reference now starts outputting another file.

[bradleypeabody]

Plan is to make github.com/vugu/vugu/js as a mirror of syscall/js that fully delegates in wasm (ideally with zero overhead), but then in non-wasm it is dumbed down and all of the values are undefined, Truthy() always returns false, Get() always returns undefined, and Call() panics.

Then vugu components can just import js "github.com/vugu/vugu/js" and it does the appropriate thing in each environment. No build tags required in components. Boom

[bradleypeabody]

github.com/vugu/vugu/js is now done and being used. Closing.