Version 2 wishlist

I've been brewing ideas for `v2` for a while now (probably over a year), and I started implementing some of these ideas in a separate branch (completely rewriting the code). Inevitably, the `master` branch kept getting worked on, and it eventually fell apart.

So now I'm trying to reboot some of my ideas, but I'll take a separate approach to implementing them: I'll implement almost everything that can be done without making breaking changes, and then I'll move the project into a state of `v2`, where we can properly progress towards a cleaner API. In general, I'd much rather have a stable, minimal API, than an unstable, comprehensive API!

I've tried to assemble a list of major things I'd like to see before making breaking changes:

- [x] Use `flit` as our build system (see #382)
- [x] Use `black` for formatting (see #386)
- [x] Refactor code into logical, separate files (`client.py` is far too large)
- [x] Would help us to make proper unit tests
- [ ] ~Set up integration tests using something like [VCR.py](https://github.com/kevin1024/vcrpy)~
- [x] Clean up documentation
- [x] Fix setup (tracked in #391)
- [ ] Make @carpedm20 set up the webhook, so that tag creation / deletion is tracked as well
- [x] API rundown (Use [Google Docstring Style](https://google.github.io/styleguide/pyguide.html#38-comments-and-docstrings))
- [x] Introduction overview overhaul
- [x] Investigate tools for detecting docstring errors and spelling mistakes
- [x] Inline examples
- [x] More detailed examples (recommends good practice too)
- [ ] API coherence (`fetchThreadMessages` can't fetch "system" messages / events)

And a list of major things I'd like to change:

- [x] Drop Python 2 support (It'll probably reach it's EOL before we get everything done 😁)
- [x] Use type hints
- [x] Improve documentation with [sphinx-autodoc-typehints](https://github.com/agronholm/sphinx-autodoc-typehints)
- [ ] Consider `async` options
- [ ] See [sphinxcontrib-trio](https://sphinxcontrib-trio.readthedocs.io/en/latest/) for documentation improvements on this.
- [x] Declare a proper public API. See [trio](https://github.com/python-trio/trio) as a reference to a project that fullfulls this promise (e.g. using `_` before methods and filenames)
- [ ] Declare a concise API (e.g. document expected exceptions)
- [x] Using datetimes, see #278, is a subtask of this
- [x] Use snake_cased method names like PEP8 suggests
- [x] Fix logging (see #258)
- [x] Make a distinction between models, like `Message`, and what you can send, as parameters in `send`. Though combining these sound good idea in theory, it's really messy in practice, and not really that useful.
- [x] Make a distinction between user created models and recieved models
- [x] Building upon this idea, we can move a lot of implementations into the model instead of a central client. For example, I'd like to be able to do something like:
```py
message = Message(id="123", client=client) # Does not make an external call (since you don't need to, to interact with the message)
message.react(None)
assert not hasattr(message, "text")
# Or alternatively:
message = client.get_message("123") # Makes an external call, and returns `MessageData`, a subclass of `Message`
message.react("👍")
assert hasattr(message, "text")
```

But anyway, it's late, and I'm rambling, and a lot of the later bullet points are still pretty abstract ideas. We should focus on the most pressing points first 😁.

If you have something you'd like to put on the wishlist, or would like to point the project in a different direction, suggest away, I'd love to hear what you have to say! 😊