CO2Leakage: Visual improvements, split plots into tabs, add slider, add options for which category to use for color/markings

[AudunSektnanNR]

Ready for review.

---

• 📖 I have considered adding a new entry in CHANGELOG.md, and added it if should be communicated there.

[AudunSektnanNR]

Some failing code style checks in different plugin, _map_viewer_fmu, not sure why. Tests in co2_leakage should be fine.

[andreas-el]

Some failing code style checks in different plugin, _map_viewer_fmu, not sure why. Tests in co2_leakage should be fine.

This will likely be resolved by #1274 and should not be affecting this PR.

[andreas-el]

This PR could benefit from some cleanup and rebasing prior to reviewing. Most commits with Fix pylint|black|mypy. Merge pull|branch etc should not be committed to master/main regardless.
Do you intend to keep some of the commits separate from others, or were you planning to squash the whole PR once approved?

[AudunSektnanNR]

This PR could benefit from some cleanup and rebasing prior to reviewing. Most commits with Fix pylint|black|mypy. Merge pull|branch etc should not be committed to master/main regardless. Do you intend to keep some of the commits separate from others, or were you planning to squash the whole PR once approved?

The plan was to squash all the commits when merging into the master branch. This is what we have done in earlier pull requests, even though the pull request might consist of changes that are not always related to each other (other than being in CO2Leakage-plugin). Should we change this approach? I guess the alternative is to make separate issues in this repo and make a pull request for each issue separately (or combine a few issues in one PR, but with 1 commit per issue).

[andreas-el]

This PR could benefit from some cleanup and rebasing prior to reviewing. Most commits with Fix pylint|black|mypy. Merge pull|branch etc should not be committed to master/main regardless. Do you intend to keep some of the commits separate from others, or were you planning to squash the whole PR once approved?

The plan was to squash all the commits when merging into the master branch. This is what we have done in earlier pull requests, even though the pull request might consist of changes that are not always related to each other (other than being in CO2Leakage-plugin). Should we change this approach? I guess the alternative is to make separate issues in this repo and make a pull request for each issue separately (or combine a few issues in one PR, but with 1 commit per issue).

First off, I'm not deciding anything here, only voicing a single opinion.
I think as a general rule that you should rebase/squash/merge some of the commits to make reviewing easier.
When you do these merge-commits inline, this becomes much more difficult.