Add plugin interface for packaging formats

### What is the problem or limitation you are having?

At present, each platform can support multiple packaging formats. For example, macOS supports .app.zip, DMG and PKG; Windows supports .zip and MSI.

However, these are all hard coded. We should add a plugin interface that allows third-parties to register their own distribution formats.

### Describe the solution you'd like

It should be possible for a user to define a Python package that contains a class compliant with a `PackagingFormatPluginT` specification, and register that plugin with Briefcase. For example, a Windows NSIS plugin might have a registration of:

```
[project.entry-points."briefcase.formats.windows.app"]
nsis = "briefcasex_nsis.plugins:NSISPackagingFormat"

[project.entry-points."briefcase.formats.windows.VisualStudio"]
nsis = "briefcasex_nsis.plugins:NSISPackagingFormat"
```

The plugin interface will need to cover features such as:
* The name/identifier of the plugin
* a `package_app` entry point to manage the packaging process
* The filename of the distribution artefact that will be produced
* The priority of the format, based on the app and platform details
* a clear API that can be used by the plugin for signing/notarization purposes.

All existing packaging formats should be refactored to use this new interface, and be registered by default. This means every platform should have at least one packaging format registered. Ideally, there'd only be one `zip` package format, shared across multiple backends (macOS, Windows, Web, ...), as the "archival" part of the process should be common, and the "signing" part of the process should be generic behind an API.

The priority API is required to support default packaging formats. For example, macOS apps can be packaged in three formats; but DMG is currently set as a default for GUI apps, and PKG for console apps. We can't hard-code a default; so we need a way to negotiate a default. This could come in the form of plugins evaluating a "priority" based on the app defintion and other finalized app details (with 0 meaning "not usable"), and Briefcase using values 1-10 to indicate relative preferences of other formats. The highest non-zero priority plugin would be the default.

For example, a macOS DMG plugin would return a priority of 10 a GUI app, but 0 for console apps. On Linux, an app would use platform detection to select the default packaging format, so DEB format would return 0 unless you're on a Debian-compatible machine, or the command has been invoked using the `--target` option.

### Describe alternatives you've considered

Status quo - keep packaging formats as hard-coded features of Briefcase.

### Additional context

This would allow us to provide a community solution for #2463 without actually committing ourselves to implementing NSIS support.

The design and implementation of #2658 and the addition of publication channel plugins may be instructive.