Add `gitfs_base` config option to set base branch

Add the ability to use a branch other than `master` as the base
environment by setting the `gitfs_base` option in the master config
file.

The Problem:
When using both a feature-branch based git workflow and gitfs, then in order
to test changes in the feature-branch, the top file in the master branch
may need to be modified. It is undesirable to change the master branch in order
to test a feature branch.

Intended Use:
This change is intended to allow for a dev/testing/staging environment
with its own salt master to dynamically change which branch to read the
top file from (with a restart of the salt master). E.g., the test salt
master can set its base branch to `feature` -- which has a modified top
file -- in order to test the changes in `feature` without requiring
changes in `master`.
Merge pull request #6960 from jesusaurus/gitfs/base

Add `gitfs_base` config option to set base branch
Use the real `logging` module.

It will still be a NOOP operation since the module is already loaded.
Implement a log handlers loader which will allow extra logging handlers to be used/configured.

* Added the notion of a queue logging handler which just stores the log message records to be sent, at a later stage, to specified logging handlers.
* The previous null logging handler is now a queue handler. This allows salt not to loose any logging messages, as soon as we get the temporary logging handler going, we sync the recorded log messages with the temporary logging handler, ie, all stored log messages are sent to the temporary logging handler.
* The logging setup procedure is now:
  * Setup two queue logging handlers. One is the previous null handler, the other will keep storing the log messages until the additional logging handlers can receive them. Both will store all logging messages as soon as salt is started, without logging configured.
  * Setup a temporary logging handler which outputs to `sys.stderr`. At this stage the previous null handler "feeds" the stored log messages to the temporary log handler and is destroyed.
  * Load any additional logging handlers using Salt's loader system. At this stage, the second queue logging handler "feeds" all logging messages to any additional logging handlers configured and is destroyed.
  * Setup console logging using salt's configuration. At this stage, the temporary logging handler is destroyed since we can now properly log to the console.
  * Setup, on request, file logging.
`salt.log` is now a package instead of a module.

The necessary changes were made to assure backwards compatibility.
Added a `salt.log.handlers` module which includes a queue handler.

We now use a queue handler instead of a null handler in order to show **all** log message records, at a latter stage, when we can, finally, show log messages.
Use proper pip mirrors in `integration.states.virtualenv.VirtualenvTest.test_issue_2594_non_invalidated_cache`
The salt logging mix-ins now have it's own module.
Only subclass `NewStyleClassMixIn` if on python < 2.7
Fix `unit.log_test.TestLog.test_issue_2853_regex_TypeError` by importing salt's logging from the proper module.
Renamed `salt.log.config` to `salt.log.setup`.
Allow the loader to search on different paths internally and externally.
Remove some code which should have been removed while cherry-picking.
Some log function renaming to better describe the final intention.
Extended logging handlers should be loaded from `salt.log.handlers`.
Fix `unit.log_test.TestLog.test_issue_2853_regex_TypeError` to import the proper(renamed) logging module.
`salt.loader.Loader` tags can now contain underscores.
`salt.log.handlers` is a package now.
Implement a global exception hook which logs all uncaught exceptions. Fixes #2287.
Some formatting fixes.