Allow configuration of custom build params for macos Xcode builds in pyproject.toml

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

I would like a project configuration option in `pyproject.toml` that would allow me to configure arbitrary Xcode build params that briefcase will then inject into the `.xcodeproj` template generated by `briefcase create macos Xcode` (or maybe `briefcase build macos Xcode`, tbh i'm not sure).

for example i modified my templated `project.pbxproj` to add a param `LSUIElement = YES` (which makes the app not appear in the dock - suitable for menu bar apps, console, apps, etc) to the `buildSettings`, which in turn ends up configuring `Info.plist` for the app Xcode ends up building.

In `project.pbxproj` it comes out as the line `INFOPLIST_KEY_LSUIElement = YES;` in the `buildSettings` dictionary:
```
buildSettings = {
ARCHS = "$(ARCHS_STANDARD)";
<...snip...>
INFOPLIST_KEY_LSUIElement = YES;
<...snip...>
STRIP_INSTALLED_PRODUCT = NO;
}
```

### Describe the solution you'd like

There's a few possibilities.

* **For common xcode build switches like `LSUIElement` it might make sense to have a full blown "human legible" `pyproject.toml` configuration option.** Something like `app_is_ui_element_only = true` or `show_in_dock = false` or whatever; I have no great ideas or strong feelings on the subject.

There are of course tons of Xcode configuration options though and manually implementing them all as `pyproject.toml` options seems kind of like a Dark Path that could lead to a lot of unnecessary maintenance (x100 because Apple has a bad habit of silently deprecating or outright disabling things like Xcode environment variables and build params), so I was thinking that just an array named something like `xcodeproject_build_settings` in `pyproject.toml` with the raw key/value pair Xcode wants would be sufficient to cover everyone's needs in all cases without being all that difficult to use for someone sophisticated enough to be bundling a briefcase app.

* **So it could be something like this in `pyproject.toml` instead** if I wanted to inject `LSUIElement` and `LSBackgroundOnly` as `xcodebuild` configurations:

```python
xcodeproject_additional_build_settings = [
"INFOPLIST_KEY_LSBackgroundOnly": "YES",
"INFOPLIST_KEY_LSUIElement": "YES"
]
```

You could allow `True` instead of `YES` though I think being "closer to the metal" of Xcode's project file format will make briefcase developers' lives significantly easier in terms of template maintenance down the line.

### Describe alternatives you've considered

As described in https://github.com/beeware/briefcase/issues/1859 currently am just manually making these modifications to the `xcodeproj` files and keeping them in source control even though these files exist in the `build/` directory hierarchy which presumably should need to be kept in version control and should be able to be recreated by `briefcase create` or `briefcase build`.

### Additional context

There's some backstory on how I am using briefcase to build a bundle I later embed into another app on https://github.com/beeware/briefcase/issues/1859.

Start by tracing the macOS Xcode path used by `briefcase create macos Xcode` and `briefcase build macos Xcode`, including the `.xcodeproj`/`project.pbxproj` template generation and `pyproject.toml` configuration. Done means configured arbitrary build settings such as `INFOPLIST_KEY_LSUIElement` are injected into the generated Xcode project and can be reproduced without manually editing files under `build/`.

Written by the indexing model from the issue text.