Invoke the resolver in the same process as pipenv rather than utilzing subprocess.

[matteius]

• Invoke the resolver in the same process as pipenv rather than utilizing subprocess.
• Restore accidentally commented out part of pip validations.
• Make a test case faster (fastapi is actually got a lot of dependencies).
• Spend several hours trying to track down why the tests have random failures in parallelism:
  ** Completely trim down the conftest.py and remove uneeded arguments
  ** try to ensure the directory is totally unique for the test
  ** Realize that click's CliRunner is actually to blame and even says in the docs that its not thread safe.
  ** Convert away from using CliRunner (mostly) for some reason the graph --reverse test is a special beast with unicode characters and a sub-process in a sub-process, so just use CliRunner there only.
• Made a few edits to requirementslib but trying to keep that minimal as I intend to do more work there in other PRs.

The issue

In thinking more about the issue that arose with the resolver using a different python version, and modules maybe being out of scope, I began to wonder why we were kicking it off as a subprocess. This reduces the number of files we have to write and read back in as well as eliminate the sub-process that we simply were waiting for anyway.

The checklist

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

[oz123]

This is really great.
As we already spoke about this, I wonder why it was in the beginning subprocess.
Maybe it was a way of doing some parallelization?
We removed some subprocess parallelization code in the past.

In any case, this makes pipenv even faster.