Bump to 0.7 dev.
Add API HTTP caching support to RBTools.

RBTools now understands standard HTTP caching mechanisms, allowing it to skip
re-fetching data from a server that it already had. This speeds up access to
API resources that both support caching and haven't changed since the last time
it was accessed by RBTools.

The cached data and metadata is stored in an SQLite database within a
subdirectory of the user's home directory. The database schema is versioned,
and if the version differs from what RBTools expects, the current cache will be
invalidated and the schema will be updated.

The following caching headers are supported:

* Cache-Control
* Pragma
* Vary
* Last-Modified
* ETag
* Expires

The cache is not mandatory for RBTools to function, so it won't interfere with
scripts on locked-down servers.

A 'rbt clear-cache' command has been added that will invalidate the cache.
This is particularly helpful when testing or if something ever goes wrong.

Reviewed at https://reviews.reviewboard.org/r/6504/
Require six 1.8 or higher.

We now depend on functionality that only exists in newer versions of
six. To be sure that users don't hit any problems, we now depend on the
latest version (as of this change): 1.8.
Allow ALIASES and TREES to be merged when processing .reviewboardrc files.

This change gives special treatment to the `ALIASES` and `TREES` keys in
.reviewboardrc so that they are merged together and not overwritten
when processing multiple files.

Reviewed at https://reviews.reviewboard.org/r/6649/
Limit cache location to be in memory or in a default location.

The HTTP cache for the API now takes a parameter that determines if it is
created in memory (`create_db_in_memory`). This parameter replaces the
`db_path` parameter, which previously accepted the special value `':memory:'`
to create the SQLite database in memory. The new parameter is more
straightforward because caches will only ever be required to be created at the
default location (for normal operation) or in memory (for unit testing).

The default API cache path is stored on the `APICache` class as the
`CACHE_PATH` constant, which can be used without instantiating the class.
Becuase the HTTP cache for the API is only ever stored in one location on disk,
it can be cleared (i.e., unlinked) without instantiating the class to determine
where it is located on disk. This is important in the case where the cache
exists but has become corrupt and cannot be loaded (and so instantiation of the
APICache class will fail).

Testing Done:
Unit tests pass.

Reviewed at https://reviews.reviewboard.org/r/6648/