a few tool-version-related hiccups during installation

[TomLippincott]

Just wanted to point out a few unchecked version-bounds that make the installation process a little tricky:

• git needs to be at least >=1.8.4 for the get-deps.sh script to work (or the git submodule invocation should happen at the top of the file tree)
• GCC needs to be >= 5 to compile (I think because it requires c++14): in some situations the build points this out, but in others it reports syntax errors and a need for c++11, and only after fiddling with the cabal files did it inform that GCC 4 (which is still used by centos 7) is a non-starter
• Debian, for one, no longer has a plain "python" command, only python2/python3, and the userspace solution of building from within a venv doesn't work because there's no notion there of a "user"-install. The simplest approach might be to test for an appropriate interpreter, falling back from python->python3->python2, but the clean approach IMO would be to also create and use a venv so packages don't get installed to the user's general library-space.

[junjihashimoto]

@TomLippincott
Thank you for your pointing out these bounds.
I think it's better to include these things in the README.
What do you think?

[TomLippincott]

Some of them maybe, but the scripts could do a bit more in checking versions and alternative executable names. I'm not up-to-date on best practices for bullet-proofing this sort of heterogeneous build, I seem to remember autoconf/automake as the standard approach for checking dependencies like compiler and interpreter versions.

I'm hoping when I reach a stable point in what I'm working on to be able to help address some of these things, I don't really expect/want the core developers to drop what they're doing because the more fundamental progress of this library is what's truly impressive!