Consolidate table loading code in TableLoadingMgr

This change moves the existing code to load a table from out of the CatalogObjectCache
and into the TableLoadingMgr. The two main motivations are:
1) We now have more control over the total number of concurrent load requests (it is
defined in a single place - the TableLoadingMgr).
2) A loading cache is a bit tricky to reason about since calling get() may be a read-only
operation but also might trigger a load which would modify the cache and take a long time.
Now the catalog cache is very simple and just enforces catalog versions are strictly
increasing.

To protect against concurrent loads of the same table, the TableLoadingMgr now tracks
the in-flight loads (a map of TableName to Future<Table>). If two loads of the same table
come in the same Future task will be returned. This also allows us to perform "async" load
requests, which is helpful when working with the locking in the catalog since we don't need
to hold a lock while waiting on the table to complete loading.

To support running the FE tests, a new mock catalog (ImpalaTestCatalog) was introduced.
This catalog overrides getTable() to perform lazy loading of table metadata on access
when running the FE tests.

Change-Id: I673eca93fc825fd553ee53a6f4bf5c5c566b8d31
Reviewed-on: http://gerrit.ent.cloudera.com:8080/1580
Reviewed-by: Lenni Kuff <lskuff@cloudera.com>
Tested-by: jenkins