Studio/uses mixed modulestore

https://edx-wiki.atlassian.net/browse/STUD-1540

**MixedModuleStore API**
* Updated Studio and LMS so all callers, with a few exceptions, go through the `MixedModulestore`.
  * to find the exceptions (a few tests and 2 management commands), search for callers to `_get_modulestore_by_type`.
* Updated the `MixedModuleStore` API and all their callers to take in the `user_id` for all Edit operations.

**Mongo Modulestore**
* Callers should no longer distinguish between 'direct' and 'draft' Mongo modulestores.  All users of the Mongo store now always go through the `DraftModuleStore`.
* Callers can specify whether they want only published versions in their runtime by configuring the modulestore's branch to 'published' (LMS).  The default setting is 'draft' (used by CMS and Preview) which prefers Draft versions over Published versions.
* Since (most) test code now go through the Draft store, some tests needed to be updated to explicitly Publish their newly created items if they assumed they would be in that state.
* API changes:
  * Updated APIs for `has_item`, `get_parent_locations`, `get_items`, and `delete_item` to take in a `revision` parameter.  Refer to docstrings for more detail.
* Improvements to the implementation of the following APIs:
  * Publish - so it automatically publishes all the downstream children.
  * Delete - so it does the "right" thing depending on which revision is deleted, etc.

**Settings**
* Changed the configuration setting format so the Stores listed in the Mixed configuration can be ordered by preference, via a `list` rather than a `dict`.
* Updated the settings for all Test code so they should all go through Mixed, unless they are explicitly testing a particular store.
* Introduced a new Setting called `MODULESTORE_BRANCH` that specifies the default "branch" (draft or published) to be used by relevant modulestore methods.  Currently, the `DraftModuleStore` uses this setting.  Eventually, the `SplitModuleStore` will also honor it.

**Testing**  @jzoldak 
The following should be tested before Release:  
* Performance - new indirection through Mixed (for CMS) and through Draft (for LMS).
* Preview from Studio - make sure both Draft and Published items are seen correctly.
* Migration of very old roles since 0036_access_roles_orgless.py was changed.
* Different configurations - devstack, non-devstack, sandbox, prod.
* Which tests have multiple stores configured at once (xml and old mongo)?
* Export/Import course - draft/published content

**Reviewers**: @cahrens (Studio) @dianakhuang (LMS) @feanil (Devops)
Hmm... this took me down a path that, now, we have TEN CONSTANTS!

I started with bringing it down to 3+1 as you suggested, but the code was getting tricky since we overload 'revision' with revisions for Keys, Branches, and API Options.  So, to make it clearer, I have separated the constants for each of these.  It should no longer matter what the underlying values are as each should be used correctly in their own context.  Now, in the future, we could even change the values for the Options to be bit-masks (so ALL could actually be DRAFT+PUBLISHED for example).

I am open to better names, but for now I have:
```
# Key Revision constants to use for Location and Usage Keys
KEY_REVISION_DRAFT = 'draft'
KEY_REVISION_PUBLISHED = None

# Revision constants to use for Module Store operations
REVISION_OPTION_DRAFT_PREFERRED
REVISION_OPTION_DRAFT_ONLY
REVISION_OPTION_PUBLISHED_ONLY
REVISION_OPTION_ALL

# Branch constants to use for stores, such as Mongo, that have only 2 branches
BRANCH_DRAFT_PREFERRED
BRANCH_PUBLISHED_ONLY

# Branch constants to use for stores, such as Split, that have named branches
BRANCH_NAME_DRAFT
BRANCH_NAME_PUBLISHED
```