Add a deb backend for Linux

[freakboy3742]

What is the problem or limitation you are having?

While AppImage and Flatpak are formats that theoretically allow distribution-independent Linux "binaries" to be distributed, in practice they have proven to be problematic (e.g., #718, #919, #1029 and more).

An informal survey of preferences revealed that despite the need for root privileges, there is a significant portion of the user base that may prefer system packages for apps, rather than a user-space friendly packaging format.

Describe the solution you'd like

Briefcase should be able to generate a deb package for an app specification.

Describe alternatives you've considered

Do nothing, and rely on AppImage/Flatpak.

Additional context

• .deb packages should work across distributions (Debian, Ubuntu, Mint etc should all be able to share packages); however, this should be verified
• As we are primarily working with Python code, .deb packages should work across distribution versions (e.g., a Debian 9 package should work with Debian 10), provided system packages are specified in ways that aren't version specific - e.g., specifying a libgtk-3 dependency should work on almost any version
• Debian-based distributions all have Python3 interpreters in their default package repositories; however, that python version will change between distribution versions. Briefcase generally guarantees that the python version used to build an app is the version used to run the app; however, we may need to (optionally) relax that requirement to apps to specify a generic "Python3" dependency, rather than a specific "3.10" dependency.
• The manylinux specification should provide all the binary compatibility guarantees that are needed; as manylinux wheels have a very specific list of libraries they can link against, as long as the .deb package guarantees that subset, any installed wheel should (?) be binary compatible.

See also #1063, #1064

[freakboy3742]

I've just discovered one issue; the bootstrap binary isn't 100% isolated from the local environment. If you run in a venv, the venv's sys.path is appended to the runtime python path; this came up for me because I had a stale version of pytest-tldr in my venv that was incompatible with the version of pytest being used in a test package (Python-support-testbed)

It's only execution in a venv that is an issue; outside of a venv (i.e, normal operation), variables like PYTHONPATH aren't picked up.

[freakboy3742]

Found the cause - as we're using the system Python, the system Python's site module will modify sys.path. The bootstrap binary needs to isolate from the site. I've updated the deb template to disable the use of the site module.