Implements qs2 serialization as an option

[shikokuchuo]

Closes shikokuchuo/mirai#162.

Adds 'qs2' as an option for all send/recv functions.

Requires the qs2 package with registered C callables reaching CRAN.

[shikokuchuo]

@traversc I'm using the parameter defaults you currently have in your header file (without actually using your header file). Let me know if you think something else might be optimal here. Thanks!

[traversc]

Default parameters are safe, but optimal depends on use case. I think it would be nice to expose the parameters somehow (or at least the compression parameter). Could be a future update.

[shikokuchuo]

The interface would get really busy. An alternative I'm thinking about is having a global switch that swaps out R serialization with qs, and that function could then possibly set the parameters.

[shikokuchuo]

Scratch that idea with the global parameter - it doesn't sit well with the design of nanonext. On the other hand, if there's a way for qs2 to set default parameters independently, then I'd be happy to use the default rather than a fixed setting.

[traversc]

By design, do you mean user interface design?

In which case I can implement global parameters in the qs2 package and you could pull from there.

Another idea, you have send_mode and recv_mode parameters -- do these need to only accept strings/integers? For example, you could also accept a list(mode = "blah", ...) where ... are additional named parameters passed to the method for mode "blah".

Just an idea, totally understand if it doesnt jive with your preference.