Subst installed Python shebangs

This substitutes the shebang in the installed Python scripts. (Scripts that are not installed by waf have been left alone.)

The Python shebang is set as follows:

1. If the user explicitly specifies --pyshebang (a new option), use that.
2. If the user explicitly specifies --python (an existing stock waf option) or its environment variable form PYTHON, use that. If it is not an absolute path, run under /usr/bin/env.
3. If the user ran waf under an explicit interpreter (e.g. python3 waf is a common idiom), use sys.executable, which is the interpreter's idea of its own name. (There is no way to get the original interpreter as typed, as sys.argv[0] is still "waf", not e.g. "python3".)
4. Use /usr/bin/env python as before.

---

Wearing my Debian hat, this would also allow me to eliminate a Debian patch.

Currently, with a compiled Python module, the scripts MUST run under the same Python X.Y that the module was compiled against, because compiled-module ABI compatibility is only guaranteed within a minor version, not across minor or major versions; see PEP 3149. This MR no longer attempts to fix this, as @jamesb_fe80 is picking up the FFI module change again which was previously !1010 (closed). The FFI change eliminates the compiled module, which moots the ABI compatibility issue.

There are three related concerns:

1. Python 2 and Python 3 have different search paths. We need one of:

   A. Don't care. If users want to switch across major versions, they can handle this themselves. This is the status quo.

   B. Subst the shebang with the path of the Python interpreter. @garyedmundsmiller is opposed because he wants to be able to flip Python versions without reinstalling. He could override the default.

   C. Subst /usr/bin/env python2 or /usr/bin/env python3. This is the approach @jamesb_fe80 took; see 6d404a9a. Presumably this is a problem for @garyedmundsmiller too, for the same reason.

   D. Drop Python 2 support. @esr suggested this and I agree.

2. waf's shebang of /usr/bin/env python (nor /usr/bin/python) does not work on Ubuntu 20.04 or CentOS 8 out of the box because there is no python. Options here are:

   A. Don't care.

   B. [intentionally omitted so options line up]

   C. [intentionally omitted so options line up]

   D. Drop Python 2 support and change waf to use /usr/bin/env python3 as the shebang. Again, @esr and I are in favor of this.

   E. Explain the problem in the docs.

   F. Keep Python 2 support, but make Python 3 the default by changing waf to use /usr/bin/env python3.

3. /usr/bin/env python (or /usr/bin/env python3) can break if the user has a custom Python higher in the PATH with a different Python search path (e.g. because of the different Python prefix). I call this the "Python in the home directory" case. Debian's Python Policy mentions this too; that's not binding here, of course, but it may be illustrative. We need to leave waf using env, obviously, to avoid assuming the location of Python for the configure step. But for the installed scripts, we could:

   A. Don't care. Python in the home directory isn't very common. This is the status quo.

   B. Subst the shebang with the path of the Python interpreter. Again, @garyedmundsmiller is opposed because he wants to be able to flip Python versions without reinstalling. He could override the default.

For item 1 (Python 2 vs Python 3 search paths), this MR punts on the issue (1A, do nothing; status quo). This would be mooted by 1D (drop Python 2).

For item 2 (no python), this MR implements 2E (explain in the docs). This would be mooted by 2D (drop Python 2) or 2F (default to /usr/bin/env python3).

For item 3 (Python in the home directory), nobody has complained to date, so this MR uses 3A (don't care; status quo).