poetry-core Add support for the `project` section (PEP 621)

Closes #567

should not be squashed

Hints:

Do not rebase without updating the downstream branch python-poetry/poetry#9135
Downstream tests were disabled because this will be breaking for downstream

Notable changes compared to #567 or "why I did not just rebase it":

Instead of two complete schemas (one legacy and one PEP 621), I decided to introduce two partial schemas (one for tool.poetry and one for project). Reasoning:
- By introducing the non-package mode, having one legacy schema and one PEP 621 schema as in #567 does not work well anymore. In non-package mode all project fields are optional.
- Further, I had difficulties distinguishing the definitions of the project section and the tool.poetry section in the PEP 621 compatible schema.
- Using a complete schema makes it easier to define relations between the project section and the tool.poetry section. However, this would require heavy use of anyOf (because of the non-package mode) and this results in hard-to-understand error messages, see https://github.com/python-poetry/poetry-core/blob/7d40189393b441b975f7490845204a5598813730/src/poetry/core/factory.py#L390-L404 Thus, it makes more sense not to use anyOf and validate the relation between both sections in the validate() method anyway.
See https://github.com/python-poetry/poetry-core/pull/567#issuecomment-1962301897
- Do not introduce [tool.poetry.dependency-options] but keep [tool.poetry.dependencies], just make version optional and implement the distinction/merging of abstract dependencies ([project.dependencies]) and concrete dependencies ([tool.poetry.dependencies]).
- Do not change anything related to [tool.poetry.group]. That especially makes sense since there might be a standard way for dependency groups in the future (see PEP 735) so we can have the same distinction between abstract and concrete dependencies.
Deprecate fields in tool.poetry that can be completely replaced by fields in the project section, see Factory.validate().

Mar 10 '24 13:03 radoering

another way to do this would be not-chaning poetry's internal layout of configuration at all, and just mapping the project section's features into poetry's features, right?