[PATCH 0 of 7] [resend] - Improve handling remotes, origin, submodules

(sigh, someday I'll get this command line email addressing stuff sorted out - resending as I mangled Junio's email)

This patch series was inspired by several issues dealing with multiple remotes and submodules. The tests added as the last patch demonstrate the specific use pattern to be supported, and that does not work currently.

1 - user A creates a project on server "frotz" with a submodule. 2 - user B clones the project, forks it, adds a submodule, and publishes the fork on server "fork"

user A adds the fork to his working tree, via git remote add + git fetch. The desire is that: 1 - git submodule init + git submodule update include the new submdule added in the fork. 2 - The top-level project and all submodules use the same remote nickname to refer to the same server.

Breakage in 1.5.4 without this patch series is in several places:

1 - git submodule does not follow the top-level project's branch.<name>.remote in fetching, so does not try to clone the new submodule from remoe "fork" where the fork exists. 2 - If 1 were fixed, git submodule still invokes clone without "-o <remotenick>" when cloning, so each submodule would have "origin" point to a different remote. 3 - If 2 were fixed, submodule update leaves submodules on detached heads, so the remotes machinery cannot supply a remote name, and thus "origin" is used for further updates. As origin may not be defined, (e.g., for the submodule fetched from "fork" this also fails.)

The underlying design issue is the assumption that all projects revolve around a single server, so that *the* server can be called "origin" without confusion. Given a project with multiple servers and no one server being *the* server, origin cannot be usefully defined. Absent submodules, the remotes machinery largely masks this: origin is referred to only as the default remote and it is easy to avoid using the default remote. With submodules, this becomes more of an issue.

Following this patch series, the following is true:

1) The existing workflow of top-level and all sub-modules always
cloned from and interacting with a single default remote
nick-named "origin" is unchanged.
2) Via clone -o <nick> (or git confit core.origin <nick>), the
default remote is changed from origin to <nick>, and that default
is used instead of origin everywhere.
3) git-submodule uses the top-level's branch.<name>.remote to
choose which remote to fetch from, uses that in all submodules,
including defining that in existing submodules whose url is
relative (../* or ./*) indicating the submodule is maintained on
same server as top-level.

The penultimate patch addresses a basic usability issue, allowing addition of a submodule in place in a project, rather than requiring it be cloned from a remote. This hole in the porcelain became evident in creating a test (t7401) for this series. submodules except by cloning).