Throw an error when backend-path is specified

[pganssle]

According to the most recent incarnation of PEP 517:

• The backend code MUST be loaded from one of the directories specified in backend-path (i.e., it is not permitted to specify backend-path and not have in-tree backend code).

The first restriction is to ensure that source trees remain self-contained, and cannot refer to locations outside of the source tree. Frontends SHOULD check this condition (typically by resolving the location to an absolute path and resolving symbolic links, and then checking it against the project root), and fail with an error message if it is violated.

Given that frontends are not guaranteed to enforce that the build backend is on the relevant backend path but projects are required to use backend-path, it is an error if a project specifies setuptools.build_meta as their backend and specifies backend-path.

I think we can make this a hard error, then when it's time to solve #1644, we can write a simple in-tree "wrapper backend" that is not shipped with setuptools but wraps setuptools.build_meta.

Assuming we're doing #1689 or #1688, we'll need to vendor pytomland parse the pyproject.toml file anyway, so I don't think this is a huge problem for us to do this as well.

[pganssle]

It would be nice to get this implemented and released before the first version of pip that supports the new PEP 517 extension, so that there's no gap of time where someone might accidentally start relying on this, though hopefully pip will also be enforcing this anyway.

[jaraco]

This feels like another situation where the frontend should be providing the guarantees. In fact, the PEP specifically says that "Frontends SHOULD". I know each backend, including setuptools, could enforce this constraint, does it make sense to enforce it in the backend? Why not enforce it in the frontend?

I'm not following the issue exactly. Perhaps you could elaborate? Can you give an example of a situation where this error would be triggered?

I'm generally not opposed to what you've presented here, and happy to see any number of packages added to the vendored libraries (including pytoml).