Refine process of building local environments

[truth-quark]

The process of building a local runtime environment on Gadi is sub-optimal & needs repair.

Elements to consider:

• Discard the source configs/insar.env & setup.py approach? (setup.py contains another list of dependencies different to requirements.txt for venv)
• Create/evaluate a hybrid virtualenv / NCI based module system for dependencies?
• Is using venv on gadi possible?
• Which smaller NCI/DEA modules provide access to gdal and Python osgeo?
• Tweak paths to point to local git repo of gamma_insar instead of using a version installed in ~/.digitalearthau. This prevents environment rebuilds being required every time the git repo is updated & speeds up development/job runs.
• Was the dea module base version changed from the InSAR hardcoded "default" 20191127? What effects does this have on the environ for InSAR?
• source configs/insar.env has a v10 group dependency, requiring new users to join a DEA Operations and code repo (this may not be suitable).
• Does the PYTHONPATH need any further tweaks?

This is related to the problem of multiple requirements files (#170).

[mwheeler]

Addendum to this, after multiple experiences w/ people trying to run this from InSAR team - we should also look at completely dropping the need for any kind of luigi.cfg

Any 'required' variables from there should have production-ready defaults (even our existing luigi.cfg doesn't have those), that aren't in a file but rather the default parameter values out-right (and some of those parameters shouldn't even be Luigi parameters, see: #213 - for things like multilook - which also confuses InSAR team who are used to / setting multilook in .proc files then having nightmares from the luigi value being used)

tl;dr - luigi.cfg shouldn't be required / we shouldn't be setting LUIGI_CONFIG_PATH at all