Add our standard GitLab CI configuration and tweak the project to be CI
friendly:

* A simple Dockerfile is added which builds an image which can run tox.
* The tox.ini is updated to save JUnit reports where our CI expects to
  find them and to add coverage XML reports.
* Remove the Circle CI badge from the README. We have GitLab CI badges
  set up for the entire UIS group in GitLab so we don't need any
  additional configuration.

Update 2019 salary scales and tax table

Added the link to the HMRC page used to provide details for 2018/2019

Updates the salary_scales as per the current single salary spine
available at https://www.hr.admin.cam.ac.uk/pay-benefits/salary-scales

Table added for the tax year 2019/2020 as per
https://www.gov.uk/guidance/rates-and-thresholds-for-employers-2019-to-2020

support CPS (pre-2013) pension scheme

Support Clinical pay scales

support a grade of "None"

If the grade is "None", we still use the point in the mapping tables but
annual increments do not occur. This allows one to model unknown grades
as being mapped to a single salary spine point for the duration of the
employment.

Add CPS pre-2013 employee and employer rates along with a test that it
matches the table on the HR website.

Closes #6

Add a new constant, ucamstaffoncosts.salary.scales.CLINICAL_SCALES which
represents the pay scales for clinical staff.

Add the clinical pay scale data table to the data directory.

Add a script to parse the clinical school pay scales to source_data and
update the README to describe how these scripts are run.

Add the parsed tables from this code.

Add HTML source data for the clinical pay scales.

The source data is simply downloaded from
https://www.hr.admin.cam.ac.uk/pay-benefits/salary-scales

implement MRC pension scheme

Implement MRC pension scheme which is fixed at 15.9%.

implement a fuller calculation

If the function is called with until_date <= initial_date, the internal
list of salaries is empty. In this case we should loop without yielding
a result.

The occupancy field is easy to add since it just scales the base salary.
Add it in in order to increase the number of roles we can model.

Separate "from date" (date from which results should be returned) and
"start date" (date which employee started being employed). This allows
for an estimate of total expenditure over the life of the employment.

Move the explanation table printer into its own function for use in
further tests.

This PR implements a fuller calculation of on-costs. It is *highly*
recommended that you read the accompanying documentation for this commit
as it is quite in-depth.

Closes #7.

The term "gross salary" was used throughout but was incorrect
terminology. "Base salary" better reflects reality.

Document our plan for calculating expenditure/commitments

Although this module does not yet calculate expenditure/commitment
calculations, add a JupyterHub notebook explaining how we intend to do
this and link from the README.

Add a basic docker-compose configuration to allow running JupyterHub. We
will use this to document the method for doing expenditure/commitment
calculations.

Initial implementation