Remove camelot

[symroe]

In this PR I do a couple of things:

1. Remove the SOPN testing baseline code. This was more of a one off feature that we added to compare the existing SOPN tooling against AWS Textract. We wanted a way to validate that Textract was at least as good as our existing code. We validated this to the point where we're getting rid of the existing code (the next commit). It might be useful to have the ability to generate a baseline in future, but this code is already quite stale so I think it's better to get rid of it and write new code if we want something like this in future.
2. We kept both old and new systems for parsing PDFs into DataFrames. We don't want to use Camelot any more, partly because Textract is much better (it deals with images, for one thing), but also because it's not maintained any more. In the second commit, I remove everything I can find to do with Camelot.

A couple of extra points:

1. I've not removed all local PDF libraries. This is because we have some tooling to split up PDFs by page that relies on these libraries. There are changes I'd like to make to this system over time, but I consider that out of scope for this PR. This means we still need to install some local libraries at the system level.
2. I've removed some of the parse tables tests because they were tied to Camelot not Textract. We want something like these tests in future, but they would be testing code that is likely to change again in the near future, so I've decided to delete them with an eye to re-making them as part of future work. Again, the refactor wasn't worth the time for code that's about to change anyway.

[chris48s]

Having deleted all this code, are we now in a position to remove camelot-py[cv] from pyproject.toml, even if we have to keep the other python/system libs for PDF parsing?

---

One thing we lose by removing the Camelot backend is the ability to have a "working" local application with out connecting it to AWS. That doesn't mean we should keep Camelot, but do you think there is any mileage in having a "mock" PDF parsing backend? I am thinking we write a "parser" where you feed it any PDF and it throws the PDF away and just returns the same hard-coded list of people/parties. Worth bothering with?

---

There's a code formatting error to resolve with ruff to get the build passing.

[chris48s]

This is a bit of a tangent, but while we're getting trigger happy with the delete button, shall we bin candidates_import_from_live_site too? I reckon now we have https://github.com/DemocracyClub/yournextrepresentative/blob/master/scripts/get-prod-db.sh this is basically just going to rot.

[chris48s]

Quick thing I noticed while working on something else..
There are some tests in the test suite with a:

@skipIf(should_skip_conversion_tests(), "Required conversion libs not installed")

decorator on them. Can you double-check if that is something we can get rid of as part of this PR.

[chris48s]

I think we're getting a bit delete-happy on useful tests here.

As I've been working on #2639 I have found that the tests in this file are mostly relevant and I've found myself updating them as I go. For example there are big chunks of tests in here that are about how we parse names that are equally relevant to both textract and camelot.

Can you restore this file and go through it just removing the ones that are specific to camelot. I think we will end up keeping much of this.