New terra pipenv environment pattern

Currently, all terra apps use terra's Pipfile for the terra environment.

Unfortunately the move of pipenv to drop markered packages that are not being used by the currently locking python is causing a ripple affect, that is starting to be noticed as we upgrade some of our pythons.

• We already knew we could no longer rely on pipenv for cross platform package tracking.
• This is also limiting our ability to support different versions of python.

To combat this problem and handle other situations, a method of maintaining a terra Pipfile.lock in the project rather than in the external terra is proposed:

• Start off by copying the external/terra/Pipfile to terra_env/Pipfile.
• The Terra_Pipenv function can be part of this process, checking if the file is different every time you run Terra_Pipenv, and either tell the user it's out of date, or start an update process
• This means each terra app can lock to a specific version of python, rather than leaving it in a lose range of support, like terra is.
• Allows a specific project to use specific versions of packages it may require.
• If the CLI/workflow/service definition ever needed a third party package, this can be supported (where as now, it cannot without using PYTHONPATH.)

Start by reading external/terra/Pipfile and the Terra_Pipenv function, then compare that environment with the proposed terra_env/Pipfile. Define how Terra_Pipenv detects a changed source file and reports or performs an update. Done means each terra app can maintain its own Pipfile.lock, Python version, and project-specific package requirements.