WIP Path Cache Core v0.15 In preparation for Technical and Functional QA

Adding 0.15 Release notes here awaiting merging into master and proper release:

# v0.15.0
Improved folder synchronization and local caching. **This is a larger update and we strongly recommend testing prior to studio rollout.**

**Details and highlights:**

**Shotgun Path Cache**
- The v0.15 release introduces a stronger and more robust folder creation mechanism where the associations between folders on disk and entities in shotgun are tracked in shotgun rather than in a local file on disk (the so called path cache file).
- On application launch and folder creation, the locally cached folder database (the path cache) will be synced against the list of folders in Shotgun.
- On setups where several local independent storages are used, it is now possible to "replay" folder creation on each local machine via the path cache synchronization mechanism.
- New projects created with 0.15 will automatically have this feature enabled.
- Existing projects will behave exactly as the did before - no change.
- There is a `tank` command which can be used to upgrade a pre-0.15 project.
- There is a `tank` command which can be used to force synchronize the local cache.
- There is now a better workflow for renaming folders. Asset names no longer need to stay in sync with the created folders on disk - these can vary independently once folders have been created (although this may be confusing for users!). In order to rename or update folders, a special new tank command called `unregister_folders` have been introduced. This unregisters folders and thereby leaves space to re-create those same folders, allowing for a workflow where disk locations can be upgraded in a controlled and programmable fashion.

**Cache Location**
- The path cache file no longer exists in the primary project storage but instead resides on a user's local machine (inside `~/.shotgun` on Linux, in `%APPDATA%\Shotgun` on Windows and in `~/Library/Application Support/Shotgun` on Macosx. 
- Other cache entries have also been moved into this location - the `cache_location` property on the Engine/Framework/App base class no longer points into the cache folder in the Pipeline Configuration but rather to the local folder mentioned above. This improves performance on setups with slow networked file storage.
- The cache location is configurable per data type and can be overridden via a core hook if desirable.

**Project Configuration Files**
- The `tank_configs.yml` file which previously had to exist in each project root is no longer needed. Instead, this information is cached on disk inside the cache location mentioned above. 
- This disk cache keeps shotgun information so that the same lookup doesn't have to be carried out over and over again, resulting in overall performance improvements, especially for the `sgtk_from_entity()` method.

**Other**
- Our internal test rig has been improved and is now providing a complete shotgun emulation as part of its test harness, allowing for more realistic test setups and through testing of toolkit/shotgun interaction.
- The `move_studio` tank command has been deprecated - this is now replaced by the `attach_to_core` and `share_core` commands.
- When accessing a Shotgun API instance outside of a project/tk context, internal code is now sharing a single API handle, resulting in improved performance for several `tank` commands.


Is this a one-way thing or is is reversible?  Should we have a command to reverse it?  What problems would occur if the client didn't migrate all pipeline configurations?  If it's bad, maybe this should be a setting on the project entity in Shotgun instead?