Concurrency

Here's another try to refactor everything to allow concurrent operations.

- The `Session` now receives packets using the channel and creates `Request` objects that reference the data to parse it
- The `Request` parses the data and dispatches operations to method calls
- Filesystem methods now additionally get the (immutable) `Request` which can be used to get information on the request (unique id, uid, gid, pid). This object cannot be moved to a different task (lifetime issue since it contains only references to the real data buffer which gets reused for the next operation). So if a method needs this information, it must query them before spawning.
- Filesystem methods now don't return results, but get a (mutable) `Reply` object which must be used to report the result of the operation. This object can be moved to a different task, which allows an implementation to do work concurrently and report the result later. This will also soon allow to reply large amount of data without copying it, because we can now send a reply using references to the data. Not sending a reply at all or replying more than once is an error (which is now unfortunately checked at runtime, but the overhead should be bearable).

Todo:
- Clean up `Request` und `Reply` a bit more, maybe merge `ArgumentIterator` into `Request` and `Sendable` into `Reply`
- Use references in replies (they still use all the old data types)
- Use multiple different reply types instead of one generic one? This would allow us to remove all fuse_* types from the trait which would be nice. Instead, every reply type would have a different signature for `ok(...)` and e.g. DirBuffer could merge into the reply type for readdir.

cc @MicahChalmer (what do you think?)

closes #1 
closes #6 
closes #13