Add updated submodule references for master
Merge pull request #1597 from cdearborn/pull-req-master-3f0b870a19

Completing model level unit tests for networking [2/5]
Add updated submodule references for master
Merge pull request #1615 from cloudedge/pull-req-master-ef1c39352d

Initialize documentation during boot [2/5]
Allow something besides dellcloudedge to be used as the "origin" account.
Update Sledgehammer build to use a different EPEL mirror
Automagically figure out required proxy parameters from http_proxy
De-awkify barclamps_in_branch and make it more generic.
Update install to always run as root.

This makes like simpler.
Make sure we always have a gem site

gem sometimes chokes otherwise.
Clean up README.online-install a bit.
Epic dev rewrite to rationalize remote, release, and branch handling.

This patch migrates dev from repo metadata v.1 to v.2.
The following big changes are present:

 * Uniform remote handling across all Crowbar repositories.
   The dev tool now enforces that git remotes across all Corwbar
   repositories point at the same thing.  All remote handling should
   be performed via ./dev remote commands, and not git remote
   commands.
 * Remotes are priority sorted.
   Each remote managed via dev has an assigned priority from 1 to
   100, the lower the number the higher the priority.  The remote you
   cloned Crowbar from (previously known as "origin") has priority 5,
   the remote you back things up to (your personal remote) has
   priority 95, and everything else defaults to priority 50.  Remote
   priorities can be changed on the fly -- see README.dev-and-workflow
   for more information.
 * dev assures that tracking branches point at the proper remotes.
   Local branches that exist in remotes will be configured to act as
   tracking branches pointing at the highest priority remote that has
   that branch. Any time you update a remote (by adding, removing, or
   changing priority) or run a ./dev fetch the tracking branches will
   be updated.
 * dev does not have a hardcoded dependency on dellcloudedge.
   You can clone and setup from any crowbar repository, and dev will
   handle making sure that all the barclamps are cloned from the same
   location.
 * You can push and pull from any remote that comes from github.
   By default, pull-requests-prep and pull-requests-gen will target
   the highest-priority remote.  You can change which remote you are
   targeting with the --to parameter.
 * You can easily merge changes from any configured remote unto your
   local branches.  By default, sync will pull in changes from the
   highest priority remote.  You can change the remote that will be
   merged in with your local branches using the --from flag.
 * Submodules are a thing of the past.
   The multiple branches with submodules model of tracking barclamp
   dependencies for each build was fine when we only had 1 release
   with a few builds, but the overhead of keeping everything
   synchronized became too fragile, leading to easily losing commits.
   Instead, all that tracking information (along with per-build build
   system differences) has been migrated into the releases
   subdirectory of master.  The branching structure for barclamps is
   unchanged, and the tracking info for each build will pull in either
   the head of a release-specific branch in the barclamps, a specific
   tag, or a specific commit.
Make find_unsynced_changes handle releases and builds
Make sure we pick up the barclamp's origin remote and urlbase.

We weren't grabbing them properly when clone_and_sync_barclamp did not
clone a barclamp.
Fix up logic in clone_and_sync_barclamps a bit more.
Sigh -- migrate away from origin before messing with the rest of the
remotes, not after.