346 duckdb for benchmarking

[yaseminbridges]

Unfortunately a very large PR, however, it is for a much-needed and positive upgrade to the benchmarking code.

Before:

• Lots and lots of opening and closing of phenopacket files. For each run, the phenopacket file would be opened and the same methods for retrieving the information would be called. This means, that when running the benchmarking on the 4k phenopacket-store for 4 different run configurations, the same batch of phenopackets would be opened, call retrieval methods, and closed ~16k times.
• Used dictionaries and lists to store data from the benchmarking - making the code hard to read.
• Lots of files output from the command, making it difficult at times to navigate to the data that you want to access.
• Limited customisation to plots output from the command.

Now:

• A unique corpus of phenopackets is read in once. The data retrieval occurs once. All the data is stored in a single duckdb table for reference. So now for benchmarking the 4k corpus on 4 different run configurations, each operation is completed once.
• Eliminated dictionaries and most lists for storing data, now data is taken from a duckdb table.
• All outputs are now contained to a single db - apart from the svg plots, making it easier to navigate.
• You can now customise the output of the plot from the command - custom plot titles for all plots & naming of the runs in the plot keys are named after a specified run identifier.

This change was necessary, the overall benchmarking process is now more efficient in terms of speed, storing of data & code readability (also managed to cut down the codebase).

Finally, I have added some much-needed documentation for running a benchmark.

A general idea of how things work now:

1. Run configuration YAML file is consumed and parsed - providing all information required for benchmarking run(s).
2. Unique corpus of phenopackets is parsed and relevant gene/variant/disease information (if specified) is stored in a duckdb table (TABLE A).
3. Depending on whether gene/variant/disease benchmarking is specified for that run configuration, the standardised TSV result is read in as a duckdb table (TABLE B) and used to compare against what is known from the phenopacket (retrieved from TABLE A) and the rank is retrieved and added to TABLE A.
4. Summary stats, plots, and comparisons between runs are generated from TABLE A

[yaseminbridges]

This PR fails due to the MakeFile pipeline test that executes the template runner and the benchmark command. The MakeFile could be separated out of the main PhEval repo and moved into monarch-pheval - @souzadevinicius agreed on this statement in another PR. Ultimately this PR is blocked until the test is refactored in the MakeFile pipeline OR this is moved to another repo to test the pipeline.

[souzadevinicius]

This PR fails due to the MakeFile pipeline test that executes the template runner and the benchmark command. The MakeFile could be separated out of the main PhEval repo and moved into monarch-pheval - @souzadevinicius agreed on this statement in another PR. Ultimately this PR is blocked until the test is refactored in the MakeFile pipeline OR this is moved to another repo to test the pipeline.

The pipeline test needed to be modified due to the pheval-utils methods refactor. Sorry for this PR blocking. @yaseminbridges, @julesjacobsen and @matentzn, wherever you decide to put the Makefile code, I agree 😅.