This is a pretty involved PR, so it may take some time to review.

Features

This PR addresses most of the issues in #181 and #152. In particular:

The pipeline runner uses a priority system to choose the next task to run, based on
- Number of times a task can run and its net consumption per iteration
- Base priority as set by the user
- Pipeline config order
A task which is a pure producer (i.e. has no input keys) will never be available, meaning that these will only run when nothing else is able to do anything
A task will not be able to run next if setup did not run successfully
Separate the selection of task to run next from the main run loop, which makes it easier to implement different task selection methods
Include a legacy option which will mimic the current pipeline behaviour
Add two extra task config features:
- limit_outputs: restrict the number of times a task can produce output in the next state. Once this limit is reached, the task will immediately advance its state.
- base_priority: priority modifier which is added to the calculated priority. Can be negative.

Two other features are added which are helpful for memory analysis:

A function to find the total memory footprint of an object, including any objects it references.
A monitoring function in PSUtilProfiler which checks memory usage every 0.5 seconds in an attempt to log peak memory used by a task

Refactoring

Additional refactoring of parts of pipeline.Manager class related to initial task loading and pipeline creation. This does not change any behaviour, but slightly improves the distribution of responsibility between methods
Update to use f-strings

[ ] Input broadcasting. This is tricky as the task would likely have to know how many total inputs to expect for each queue (i.e. how many total combinations of inputs), so it would have to wait for all inputs to accumulate instead of clearing them as soon as possible

Note: this re-implements the multi-output functionality of #263, but that has some extra tests