[aui]: add new port

[Saikari (luadebug)]

• Changes comply with the maintainer guide.
• The packaged project is mature and ready for broad sharing with vcpkg users
  • Has a release at least 6 months old or 6 months of demonstrated public development
  • Is an official component of something else meeting that criteria
  • Some other reason (please explain)
• The packaged project shows strong association with the chosen port name. Check this box if at least one of the following criteria is met:
  • The project is in Repology: https://repology.org/project//versions
  • The project is amongst the first web search results for "" or " C++". Include a screenshot of the search engine results in the PR.
  • The port name follows the 'GitHubOrg-GitHubRepo' form or equivalent Owner-Project form.
• Optional dependencies of the build are all controlled by the port. A dependency is controlled if it is declared an unconditional dependency in vcpkg.json, or explicitly disabled through patches or build system arguments such as CMAKE_DISABLE_FIND_PACKAGE_Xxx or VCPKG_LOCK_FIND_PACKAGE
• The versioning scheme in vcpkg.json matches what upstream says.
• The license declaration in vcpkg.json matches what upstream says.
• The installed as the "copyright" file matches what upstream says.
• The source code of the component installed comes from an authoritative source.
• The generated "usage text" is brief and accurate. See adding-usage for context. Don't add a usage file if the automatically generated usage is correct.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Exactly one version is added in each modified versions file.

Continue of #53142

[Billy O'Neal (BillyONeal)]

Thanks for the new port!

Thanks for the new port, only one nitpick I think needs to be fixed before we can merge it. Couple of issues GPT 5.6 Sol reports:

The aui public headers are not usable through direct integration. Declarations use API_AUI_* macros that are defined only by the custom CMake targets, so compiling against the installed root include/ directory without extra build-system definitions fails.

It's OK for direct-include to not work but it would be nice; e.g. by emitting these somewhere in a shared configure header so that build system bindings aren't necessary to use the component.

The package installs Gradle wrapper JARs under both platform/ and debug/platform/. Those binaries are Apache-2.0 content, but vcpkg.json declares only MPL-2.0 and portfile.cmake installs only AUI's MPL notice.

This is the only thing to "request changes" over here; I would normally submit a PR against you with a suggested fix but I'm not sure what course of action to take (remove installing those bits or declare the licensing appropriately)

Note to other contributors/reviewers: This is a level of patching we would normally not accept but we have significant contributor for the component making the submission here. That said Saikari (@luadebug) it would be nice if you can get a version out with this stuff fixed at some point.

Generated usage still instructs users to link oboe::oboe, an Android implementation dependency, rather than an AUI target.

Might be nice to fix this while you're here but not strictly rquired.

[Billy O'Neal (BillyONeal)]

Review note: The contributor Saikari (@luadebug) contributes here so the usual rules about upstream submission do not apply.

No change requested.

[Billy O'Neal (BillyONeal)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Billy O'Neal (BillyONeal)]

The ones github reports as cancelled are running :)

[Billy O'Neal (BillyONeal)]

Thanks!