Json cleanup and improvements

### What I have done is:

* Tried to make the code more idiomatic
* Renamed the `wr` field of the `Encoder` and `PrettyEncoder` structs to `writer`
* Replaced some `from_utf8` by `from_utf8_owned` to avoid unnecessary allocations
* Removed unnecessary `unsafe` code
* **Removed unnecessary `box` from enum variant (`Object(Box<Object>)` becomes `Object(Object)`)**
* Added `encode` and `decode` shortcut functions
* Implemented `FromStr` for `Json`
* Implemented `ToJson` for tuples of arity up to 12
* Fixed some details in the documentation

### Questions

* The `encode` shortcut function does the same as the `Encoder::str_encode` function. It seems wrong to me that two functions do exactly the same. Should we deprecate `Encoder::str_encode`?
* ~~Do we really want the ToJson trait for tuples? At the moment we have it for (), (A, B), (A, B, C). I would like to remove them.~~
* ~~We are using `String` as key in the `TreeMap` representing a `Json` object. It would be better to use `&str`, but this would require to annotate lots of lifetimes. Is there any easy solution for this?~~
* There is a lot of duplicated code (`PrettyEncoder` copies about 50 lines from `Encoder`). In an OO language this could be solved very elegantly by using inheritance and overriding. What can we do here to reduce the amount of boilerplate?

[breaking-change]
I think symmetry is important for the users of the library. If you can use `json::decode`, it looks natural to have `json::encode` as well. Maybe it would be a good idea to remove `Encoder::str_encode` in favor of `json::encode`.