Change license to Apache2, add ability to build+publish to PyPi

Hi @duncan (also pinging @mwebster), this MR proposes a couple of things:

• Change the source code license that covers fsl_sub from the FSL license to the Apache 2 license
• Enhance the Gitlab CI pipeline to include jobs that:
  1. Build source and wheel packages (build-pypi-dist)
  2. Upload those packages to PyPi (deploy-pypi-dist)

The build-pypi-dist job is run in every CI / CD pipeline - this can be useful to catch changes that break the build for some reason (e.g. errors in setup.py).

The deploy-pypi-dist job is only triggered when a new tag is added to this repository; this job must also be manually invoked, and requires PyPi login credentials to be set as CI / CD variables called TWINE_USERNAME and TWINE_PASSWORD on this repository.

For the time being, fsl_sub will continue to be published to our internal conda channel (via the fsl/conda/fsl_sub recipe repository). But once we have fsl_sub up on PyPi, we can configure publishing to conda-forge.

There is a potential package naming issue that we will need to think about:

• FSL is installed from two conda channels:

  - https://fsl.fmrib.ox.ac.uk/fsldownloads/fslconda/public/ 
  - conda-forge

• Conda channel order is important - packages in higher channels take precedence over packages in lower channels.
• Recent conda versions default to enforcing strict channel priority - this means that Packages in lower priority channels are not considered if a package with the same name appears in a higher priority channel (see Managing channels).

So if we publish new versions of fsl_sub (under that name) to conda-forge, these versions will be masked by the older versions already available on our fslconda/public channel.

The only two work-arounds to this problem that I can think of, which will not break installation of existing FSL versions, are:

1. Publish the package to conda-forge under a different name, e.g. fslsub
2. Publish the package to conda-forge under the same name, i.e. fsl_sub, then remove all versions of fsl_sub from fslconda/public, and retroactively re-publish those versions to conda-forge.

I would personally vote for option 1, as removing packages from conda channels can be problematic.