Repart by CPU ticks with optional fixed costs

Change the weights used for repartitioning to either measured CPU ticks and/or fixed costs based on the mean time per task type. Both these techniques give very good partitioning, but deriving fixed costs requires a run of SWIFT to the first unforced repartition, so we use only ticks by default.

So we will now normally assume a good enough initial partition (based on the particle memory use per rank) and run with that until the first step that interacts all the particles (or nearly all). That step produces ticks for all tasks, which then give the weights.

The fixed costs are calculated and dumped at repartition steps into a file partition_fixed_costs.h which can be used to replace the dummy version in src/, after which SWIFT can be recompiled and fixed costs tuned to the correct run are available. When requested these are used after the second step to give a partition that will be used until the first unforced repartition, when ticks are used once more. There is an option to only use fixed costs, when available for all repartitioning, but that should be used as a development tool.

As part of these changes the way that task dumps are generated has changed a little (the code for this is moved into a more obvious function in task.c). The -y flag is now always available and outputs a stats analysis of the tasks, so we can easily seen the costs of tasks. The fuller dumps still require the configuration option to be applied.

Note that this decouples task weights from repartitioning as scheduling needs to be done with partial information, for that we still have an issue with tasks that do not have characteristic functions that scale with particle counts.

We also now have a repartition type "memory" that replaces "costs/none". This balances by memory use by particles in the cells. Also all the repartition types have been relabelled to use simple non-compound names.

Finally we have some RTD docs.

Supercedes !686 (closed)