1-line-installer: facilitate testing w/ instant install of CLI-specified PR's e.g. 'sudo iiab 361 2607'

[holta]

Automatically installs PR's from iiab/iiab and iiab/iiab-admin-console so IIAB's testing community becomes more organized.

Requires a companion PR [iiab/iiab#2608] so that iiab-diagnostics reports /etc/iiab/pr-list to IIAB's support community, helping to coordinate with the above people who dedicate themselves to the very hard work of testing.

Aligning this PR with the best parts of @jvonau's PR #156 might also be possible.

[holta]

Most all of this code is error-handling with a (somewhat) colorful text mode front-end, so community volunteers can survive git's various failure modes in plain English, without having to look over the edge into its chasm of complexity.

The point is to embrace dedicated volunteers helping beta-test upcoming IIAB features, by involving bright people who don't know what a PR is — and quite frankly don't want to know. People who have exceptional talents in other areas, to help Internet-in-a-Box become an even higher-quality global community product.

All they need now is a bunch of PR numbers, so they can install IIAB with a bunch of PR's (Pull Requests) by running things like:

sudo iiab 361 2604 2607

The above installs IIAB with PR's iiab/iiab-admin-console#361, iiab/iiab#2604 and iiab/iiab#2607.

Non-technical people would use this 1-line-installer (http://download.iiab.io) to do exactly the same thing:

curl d.iiab.io/install.txt | sudo bash -s 361 2604 2607

While installing IIAB, sudo iiab is sometimes interrupted (for good reasons, e.g. rebooting after security updates, editing local_vars.yml, etc) and so needs to be re-run to continue. When sudo iiab is re-run at these times, more PR's can optionally be added to the queue (/etc/iiab/pr-queue) e.g. if you forgot one while doing your OS security updates/reboot ...or while editing /etc/iiab/local_vars.yml ...or if a new PR appears 10 minutes later.

For example if you suddenly realize you want to try out PR iiab/iiab#2609 (best to do this before Ansible gets too far along) then run the following to add PR 2609 to your IIAB install:

sudo iiab 2609

Most importantly, non-technical implementers can just keep typing in sudo iiab without having to think, and the 1-line-installer will walk them through the process, with tips in case a PR is not available, not mergeable, or typo'd etc!

Finally, sudo iiab will try to alert you to fix your /etc/iiab/local_vars.yml if any of the just-installed-PR's appears to have changed the structure of your local_vars.yml file. So testing volunteers have the very latest — without having a stale local_vars.yml file waste their time (and everyone's time) with inappropriate testing.

More explanations in Section I. herein:
https://github.com/iiab/iiab-factory/blob/master/iiab#L244-L319

PR's that have been successfully applied are listed (with human-readable timestamps) in /etc/iiab/pr-list-pulled so that everyone can keep track e.g. with iiab-diagnostics.

Heavily tested on Ubuntu Server 20.04.1

(Nothing here should be OS-dependent if a recent version bash is installed, I hope!)

[holta]

FYI the core git pull flags might be improved (on Line 307) considering this warning that appears occasionally:

warning: Pulling without specifying how to reconcile divergent branches is
discouraged. You can squelch this message by running one of the following
commands sometime before your next pull:

  git config pull.rebase false  # merge (the default strategy)
  git config pull.rebase true   # rebase
  git config pull.ff only       # fast-forward only

You can replace "git config" with "git config --global" to set a default
preference for all repositories. You can also pass --rebase, --no-rebase,
or --ff-only on the command line to override the configured default per
invocation.