Use feature flag to enable wasm builds

[nothingismagick]

Closes #151.

This just adds a feature flag (and relevant uuid feature) that allows devs to conditionally compile riker for wasm runtimes.

[nothingismagick]

I didn't mention that I tested this both with build and test (on macos).

[nothingismagick]

This can get merged, its a non-breaking change.

[lukewestby]

@nothingismagick does this need to be made more general? futures::executor::ThreadPool isn't supported in WASM yet.

https://github.com/nothingismagick/riker/blob/master/src/system.rs#L269

[siriux]

@lukewestby I'm working on an agnostic executor library to enable riker to use different executors, including WASM. That would be a first step into making riker wasm compatible.

https://github.com/riker-rs/riker/pull/152

But it's not only the threadpool, it's also integrating with timers (also supported by the new library), testing with wasm-pack, using channels that work in WASM (it can be tricky sometimes) and I'm sure many more things.

[lukewestby]

Understood. Thank you!

[siriux]

Just to let you know, I'm not sure anymore that riker can ever support WASM without major changes. That's because WASM doesn't support catching panics, and riker heavily relies on this for its supervision model.

And even if major incompatible changes were introduced to fix that, there are still many more things to fix.

Sure, it could be done, but it's probably better to create a lighter actor library from scratch, with WASM and agnostic executors support baked in from the beginning. And leave riker for the server use case that was designed for.

[nothingismagick]

WASM isn't just for the browser and riker isn't just for a server... Just saying

[siriux]

Sure. Let's just say current riker design is not really WASM friendly. Anyone can apply it to their own use case ;-)