Feat/remove duplicated dependency declaration

[redur]

All dependencies are now directly managed in the pyproject.toml file.

Please consider the following:
Since we're developing a python package that is intended to use in combination with other python code and packages, we should keep the dependency restrictions as weak as possible. On the production side on the other hand, we want to fix all dependencies to fix the behavior of the production service.

We now made the shift from a fixed environment to declaring dependencies for the swissgeol-boreholes-dataextraction package. Therefore I tried to lift as many restrictions as possible. I believe we could further lift restrictions. I.e. do we really need python>3.10?
As we're the only users for now it is not an issue, but something to consider in the future. We also need to be careful, every time we notice some dependency issues, we have to adapt our restrictions in pyproject.toml.

Another note: I kept the restrictions for the dev dependencies rather fixed (I don't call them dev any more, but rather split them into test,lint,experiment_tracking & visualize. I haven't wrapped my head around if it really makes sense to have that many.
Test can be used for the testing CI.
Lint can be used for the lint CI.
Experiment tracking should be installed for local development (alongside with test and lint).
Visualize was something we used in a notebook, there's no need for a general user to install visualize. We could even think of removing this extra dependency alltogether.

[github-actions]

Coverage Report

File	Stmts	Miss	Cover	Missing
src/stratigraphy
__init__.py	8	1	88%	11
extract.py	210	210	0%	3–506
get_files.py	21	21	0%	3–48
line_detection.py	26	26	0%	3–76
main.py	91	91	0%	3–234
src/stratigraphy/util
coordinate_extraction.py	117	20	83%	27, 47, 51, 55, 59–67, 88, 164, 184, 273, 276–277, 281, 293
dataclasses.py	32	3	91%	37–39
depthcolumn.py	208	67	68%	26, 30, 51, 57, 60–61, 85, 88, 95, 102, 110–111, 121, 138–154, 199, 238, 254–262, 274, 279, 286, 313, 323, 352, 373, 376–387, 402–403, 448–490
depthcolumnentry.py	20	4	80%	12, 15, 27, 34
description_block_splitter.py	70	2	97%	24, 139
draw.py	73	73	0%	3–225
duplicate_detection.py	51	51	0%	3–146
find_depth_columns.py	89	6	93%	41–42, 70, 82, 175–176
find_description.py	63	28	56%	27–35, 50–63, 79–95, 172–175
geometric_line_utilities.py	86	2	98%	82, 132
interval.py	107	52	51%	25–28, 32–35, 40, 45, 48, 100–146, 167, 172–188
language_detection.py	18	18	0%	3–45
layer_identifier_column.py	91	91	0%	3–227
line.py	49	26	47%	25, 42, 51, 65–95, 98
linesquadtree.py	46	1	98%	76
plot_utils.py	43	43	0%	3–120
predictions.py	186	186	0%	3–386
textblock.py	74	8	89%	27, 51, 63, 75, 98, 119, 127, 155
util.py	40	22	45%	15–18, 22, 26, 40–47, 61–63, 87–88, 100–105
TOTAL	1819	1052	42%

Tests	Skipped	Failures	Errors	Time
58	0 💤	0 ❌	0 🔥	1.041s ⏱️

[redur]

Note: Currently only local installation using pip install -e . For non local installation we need to find a way to provide the config files. I will open an issue for that.

[redur]

#55

[redur]

For the optional dependencies, we don't need to be that strict. I.e. we don't need to weaken the version as this is very much related to development and not for production purposes.

[redur]

Since we look at the pyproject.toml file in this PR, I open the discussion about the package name.
Would it make sense to rename the package to boreholes-dataextraction? Or maybe swisstopo-boreholes-dataextraction? We could also think about shorter names.

Further, do we plan to publish the package on pypi at some point?

[stijnvermeeren-swisstopo]

Since we look at the pyproject.toml file in this PR, I open the discussion about the package name. Would it make sense to rename the package to boreholes-dataextraction? Or maybe swisstopo-boreholes-dataextraction? We could also think about shorter names.

Further, do we plan to publish the package on pypi at some point?

1. We could use swissgeol-boreholes-dataextraction. Also the script command (currently "boreholes-extract-layers") should probably be generalised, as we no longer only extract layers.
2. No immediate plans yet, but it could be a logical step in the future. Would this choice have any influence on the development at this point in time?

[redur]

Since we look at the pyproject.toml file in this PR, I open the discussion about the package name. Would it make sense to rename the package to boreholes-dataextraction? Or maybe swisstopo-boreholes-dataextraction? We could also think about shorter names.
Further, do we plan to publish the package on pypi at some point?

1. We could use swissgeol-boreholes-dataextraction. Also the script command (currently "boreholes-extract-layers") should probably be generalised, as we no longer only extract layers.
2. No immediate plans yet, but it could be a logical step in the future. Would this choice have any influence on the development at this point in time?

1. For me it would make sense to divide the commands a bit further. Something like boreholes-extract-all, boreholes-extract-layersand boreholes-extract-metadata. This would go in line with the discussion we had about the architecture, and the possibility to redo certain steps given some constraints. I am fine with the name swissgeol-boreholes-dataextraction.
2. We are preparing for that step already using pyproject.toml. However, at the moment the package is meant to be used using the source code as we provide the config file with the source code. I feel we need a solution for that problem anyways.

[redur]

Comments are addressed. Let me know if it's all good now.

[redur]

Follow up ticket in Jira is created.