…tats

Adding RI code to handle and break odd crossings

…sheffield/topology

Fixes a bunch of linting errors, some notes left in place for tasks to be completed (e.g. see #899).

Closes #899

Also updates `test_process_stages()` although this includes disabling a one set of parameters for the time being until I
work out what is now happening.

…way from the crossing branches for tracing

Fixes a bunch of linting errors, some notes left in place for tasks to be completed (e.g. see #899).

Within `processing.run_splining()`...

+ `grainstats_additions_image` > `splining_stats`
+ `grainstats_additions_df` > `_splining_stats` (prefix of `_` denotes private object)

Within `topostats.tracing.splining_image()`

+ `grainstats_additions_df` > `splining_stats_df`

…tle/800-splining-tests

+ `test_create_empty_dataframe()` didn't have `molecule_number` reverted to `grain_number`.
+ `topostats.utils.update_plotting_config()` had a clause which only checked if an image was in the `core_set` and
  failed if it then didn't have a `mask_cmap` entry.

+ `blu` > `blue` in `test_mask_dilation()` and `test_mask_cmap()` to reflect change in `topostats/theme.py`
+ deduplicate `# pylint: disable` from `topostats/plottingfuncs.py`

…sheffield/topology

…elf args

Add trace smoothing tests

…ct_nodes_nearest

…ordered

…image

… /tests/tracing/*.py

…ibility

…ata types

…ld test output files

The section which automatically dilated masks had been commented out as part of the refactoring for
`better-tracing`. This meant that the related test (`tests/test_plottingfuncs.py::test_mask_dilation()`) failed.

After discussion it was decided to remove this functionality completely. We have left the
`topostats.plottingfuncs.dilate_binary_image()` which may be used elsewhere. It isn't currently but there _is_ an
argument/option in `default_config.yaml` under `mask_smoothing_params` which indicates the dilation is undertaken during
smoothing so perhaps we can simplify the code by calling the `dilate_binary_image()` function we have in place with
tests and reduce the amount of code within the smoothing module.

Further the step which turns a mask with numbered layers to binary (`0`/`1`) has been removed because plots now require
there to be different layers of masking to differentiate individual molecules.

Another issue is that the tests were developed with a value of `zrange: [null, null]` but in this branch the
`default_config.yaml` has been modified to `zrange: [-2, 6]` which results in six tests failing. The
`default_config.yaml` has been reverted to `zrange: [null, null]`.

This does raise a couple of issues.

1. What should the defaults be in the `main` branch and in releases?

When developing features and testing new code it may be desirable to use custom configurations but what should we be
using as defaults for releases? What set of values works best for _most_ use cases?

2. Use `--config <custom_config>.yaml`

Directly related to this is that we should not be changing values in `default_config.yaml` when undertaking development.
Rather we should use the `--config` flag with a custom configuration file. When new options need adding that isn't a
problem to add them to `default_config.yaml` but when modifying values it is important to ensure all tests pass.

It can take some time to track down and work out the root cause of these test failures!