_validate_pyproject has inconsistent provenance

[jaraco]

The code in _validate_pyproject is generated, so includes vendored copies of the validate-pyproject project and its dependencies, but it doesn't follow the pattern for vendored dependencies, leading to confusion when users suggest changes to that code. It's unclear to me, even after reviewing the technique for generating the package, which code is generated and which code is copied (I haven't gone as far as to review the pre_compile logic).

I'd like to move this code out of setuptools or treat it like any other vendored dependency, for clarity and consistency.

In #2825 (comment), @mgorny proposed to create a new, distinct package that contains the generated code. That approach seems suitable to me. Something like setuptools-validate-pyproject. That dependency could then be vendored just like any other.

An alternative to consider would be to move the generated code into a separate git repo and use git submodules to link it in. That would create the separation, encapsulate the generated code, and provide a clear custodial trail (users couldn't link the code in this repo and wouldn't be inclined to provide PRs to it here), but it would still be integrated into the release (as it is today). I'm not confident about this approach or what pitfalls it might entail, so I'm inclined to focus on vendoring instead.

Another option could be to avoid the static generation and instead have validate-pyproject generate the code on demand. Then setuptools could simply depend on validate-pyproject or maybe validate-pyproject[setuptools,distutils] (again, vendored per Setuptools' vendoring scheme).

@abravalheri How do you feel about having a new, separate package for the validator?