Make the crate independent of xenstore C library

[TSnake41]

Add a pure rust xenstore implementation to replace the C binding.

xenstore is exposed to useland by two interfaces :

• xenstored unix socket (usually /run/xenstored/socket)
• /dev/xen/xenbus device (or /proc/xen/xenbus (deprecated path)) (or another platform specific path)

(depending on whether the domain hosts xenstored or not)

Those two interfaces follow a same protocol as defined in xs_wire.h 1 and xenstore.txt 2 using regular read/write syscalls.

Implement this protocol using pure-Rust and standard library and replace the C binding by this implementation.

[TSnake41]

Changes in b510c8f would superseed #4

[TSnake41]

I think it is good for now, there is some stuff that could be improved for the future :

It would be useful to have a interface to xenstore management commands (GET_PERMS, SET_PERMS, INTRODUCE/RELEASE, ...). That's not a really difficult to implement though.

We can make the tokio implementation runtime-agnostic by relying only on futures crate and let the user provide its own way of reading XsMessage (e.g by Sink/Stream implementations but there are caveats for now rust-lang/futures-rs#2857); and move the tokio implementation to use it. It doesn't really increase the line count, but makes supporting this crate easier with another runtime (e.g smol, async-std, ...).
It also allows using arbitrary ways of reading XsMessage (testing, xenstore ring interface, ...).
I made a small experiment at https://github.com/TSnake41/xenstore-rs/tree/generic-async

We can do a similar thing with the synchronous implementation with a wrapper for some XsMessage reader/writer to make it implement Xs.

And if we need it, have a implementation for transactions.

[Wenzel]

Overall LGTM
Thanks for the effort !

We can continue iterating on the design in future PRs as this one is already introducting a lot of changes.

Can you fix the CI (formatting) ?