Adopt PEP 517 installation mechanisms for Briefcase app code

[freakboy3742]

What is the problem or limitation you are having?

Briefcase currently implements its own custom "installation" mechanism, defining a sources list, test_sources list, and custom conventions around entry points.

This replicates a lot of functionality and expectations that exist around PEP 517.

Describe the solution you'd like

Briefcase should deprecate its own install mechanisms in favour of using PEP 517 interfaces. This would mean doing the equivalent of pip install . --target <app folder> in a packaged app, and pip install -e . for dev environments.

Describe alternatives you've considered

Retain the status quo.

Briefcase could also become a PEP 517 compliant install tool. That's a much bigger task, and I'm not sure Briefcase has much to add in this space. However, it might be helpful as a "migration" approach - move all Briefcase's app installation code into a PEP 517 build backend, ultimately allowing for deprecation of that entire module.

Additional context

Two open questions that need to be resolved:

1. How to handle test code. PEP 517 is silent on how to manage test code, since test code shouldn't normally be bundled with the package. We may need to retain test_sources handling.
2. How to handle app metadata that isn't part of the wheel metadata spec. For example, Briefcase makes a distinction between a "formal name" and an "app name"; there's no analog for this in the wheel metadata spec. This may be something where we should coordinate with the broader Python ecosystem to extend PEP 621.