Packaging is a big topic in the Python community these days. Things are
evolving, but a consensus seems to have formed around the path forward.

With PEP 518, Pip is becoming the primary tool to install Python
modules. In turn, Pip will use the right underlying tool for the job.
(distutils, setuptools, flint, ...)

Given all this, it makes sense to have a pip element in BuildStream.

This element installs a single Python module, telling Pip not to go and
download its dependencies, to make builds reproducible and not rely
on the network during builds.

By default it will use the `pip` command which generally points to Pip
for Python 2. Users can override the "pip" variable, for example to use
the `pip3` command, which generally points to Pip for Python 3.

Suggest the user to mount /etc/passwd inside the container to fix `bzr`
command.

The command `bzr` fails if the uid of the user using it doesn't exist,
giving, for example, the following back trace when running `bzr init`:

      File "/usr/lib64/python2.7/site-packages/bzrlib/lockdir.py", line 238, in _attempt_lock
	tmpname = self._create_pending_dir()
      File "/usr/lib64/python2.7/site-packages/bzrlib/lockdir.py", line 335, in _create_pending_dir
	info = LockHeldInfo.for_this_process(self.extra_holder_info)
      File "/usr/lib64/python2.7/site-packages/bzrlib/lockdir.py", line 779, in for_this_process
	user=get_username_for_lock_info(),
      File "/usr/lib64/python2.7/site-packages/bzrlib/lockdir.py", line 863, in get_username_for_lock_info
	return osutils.getuser_unicode()
      File "/usr/lib64/python2.7/site-packages/bzrlib/osutils.py", line 356, in _posix_getuser_unicode
	name = getpass.getuser()
      File "/usr/lib64/python2.7/getpass.py", line 158, in getuser
	return pwd.getpwuid(os.getuid())[0]
    KeyError: 'getpwuid(): uid not found: 1000'

To fix this there were 2 possible solutions:
- To run everything as rooat (or as another user) in the container. We
will not need to set the uid to use, making the instructions simpler.
The main problem is that the files stored in the host will probably
have a different owner, and the user will have problems with file
permissions.
- To ensure the uid of the current user also exists inside the
container.

This command adds initial cross-compilation support to BuildStream.

It has been tested against a converted version of the Baserock
compiler bootstrap and used to cross build sysroots for armv8l64 and ppc64l
from an x86_64 host.

For example, to build a sysroot for ARM v8 64-bit you can do this:

    bst build --target-arch=armv8b64 gnu-toolchain/stage2.bst

This would cause the adapted Baserock definitions to produce a stage1 simple
cross compiler that runs on the native architecture and produces armv8b64
binaries, and then cross build a stage2 sysroot that executes on armv8b64.

Currently the --host-arch option does nothing of use. It will one day
enable host-incompatible builds using a QEMU-powered cross sandbox.

The `--arch=` option is now shorthand for `--host-arch= --target-arch=`.

Elements have 2 new variables available, %{bst-host-arch} and
%{bst-target-arch}. The 'arches' conditional now follows %{bst-target-arch},
while the new 'host-arches' conditional follows %{bst-host-arch}. All
of --arch, --host-arch and --target-arch default to the output of `uname -a`.

There's no magic here that would make all BuildStream elements suddenly
able to cross compile. It is up to an individual element to support this by
honouring %{bst-target-arch} in whatever way makes sense.

Added note that script elements may only depend on other elements
as build dependencies.