Code reorg utils into utils module reduces complexity

[matteius]

The issue

The pipenv/utils.py has grown to 2338 lines of code, which makes it unwieldy and disorganized. When trying to consider larger bugs and refactors this is problematic because of the logical complexity of navigating around and understanding what kind of util you are looking at. I would like to do something similar with core.py at some point as well, but this is my first iteration of proposing reorg'ing some of the code.

#4992

The fix

Move the existing utils.py code into a utils module organized by functionality type. This is a first pass at it, and I suspect there may be some tweaking to my naming conventions to make everyone happy. The only draw back I see to doing this is loosing some of the git annotations around this code, but ultimately that would happen whenever we get around to organizing the code better and I think good code organization is more important than legacy annotations which would still ultimately be in the git history.

The only modifications to code being moved are the following methods have been dropped due to lack of use:

• escape_grouped_arguments + unit tests
• parse_python_version + unit tests
• add_to_set
• sys_version
• get_indexes_from_requirement
• interrupt_handled_subprocess
• rmtree

Also two unused code lines were removed pipenv/core.py because I had already run the test suite showing they were not used after my IDE tipped me off about that.

The checklist

• Associated issue
• A news fragment in the news/ directory to describe this fix with the extension .bugfix, .feature, .behavior, .doc. .vendor. or .trivial (this will appear in the release changelog). Use semantic line breaks and name the file after the issue number or the PR #.

[oz123]

It's a big one, I'll need a few more passes to review all of it.

[matteius]

Note: that in the fast-follow linting PR I added a new type process same as Pip has, and this news fragment is converted to a process type in the subsequent PR. I went back and forth on feature vs process for this one, but its not an end-user facing feature.

[oz123]

@matteius I think this can be merged.
@frostming want to have a look at this giant PR?

[matteius]

I am going to merge this because I need to modify a util based on a new issue report from today, and I am tired of keeping those changes in sync with this PR. It will also allow merging the linting PR.