Remove from pip/_internal/__init__.py the vcs module imports

[cjerdonek]

This is related to #4768 ("Speedup startup time"). This PR removes from pip's main __init__.py the imports from all of the vcs submodules.

Currently, pip's main __init__.py imports all of the vcs submodules. My guess is that it was done this way as the way to make sure that all of the vcs's are registered in the VcsSupport class when any vcs code is first used. (Registering a particular VCS happens when the corresponding vcs submodule is imported.) This PR removes those imports by--

1. Renaming the current _internal/vcs/__init__.py to _internal/vcs/versioncontrol.py, and
2. Moving the VcsSupport registrations from _internal/__init__.py to _internal/vcs/__init__.py.
3. (Also, the definition of path_to_url() had to be moved from the top-level download.py to utils/misc.py to avoid a circular dependency, since at least one of the vcs submodules was importing path_to_url(). This is something that should be done anyways because path_to_url() is used widely throughout the code base.)

[cjerdonek]

I pushed a new version of this PR with the file rename moved to its own commit. Now the diff is a lot more readable (when viewing the individual commits).

Here is the main commit (the third and last one shows how the imports changed): 66f55e4

[boxed]

Nice! Does this do anything significant to the import time? I didn't get any solidly measurable impact until I had done this and lots of other changes. That's why my PR is so big.

[cjerdonek]

Does this do anything significant to the import time?

No, this PR doesn't change the set of modules imported in the "common case." It's just a preparatory refactor that would make it possible / much easier to remove the vcs imports in a subsequent commit. That can be done in a subsequent PR if we want (e.g. by moving the imports into function calls like you've done).

The current PR is a refactoring change that should be done for independent reasons, IMO.

[cjerdonek]

Hi @xavfernandez, would you be able to take a look at this? It's mostly just renaming a file and updating the affected imports (easiest to see from looking at the three commits individually).

[xavfernandez]

The last 2 commits might be squashed together since 331ac9523e on its own surely breaks a lot of things :)

[cjerdonek]

Thanks, @xavfernandez!

Re: squashing those two, I thought git-bisect only looked at merge commits by default, but I guess not when I researched this. Of course, the downside is that once they're squashed, there won't be an easy way for people to see what changed in the file (I don't think). But oh well..