License: add binary license and notice files

[tuhaihe]

The source release bundles no third-party code: there is no vendor/ directory, so LICENSE and NOTICE describe the source tree correctly. The convenience binary packages are a different artifact. They are statically linked Go binaries and therefore physically contain the code of every module in the build graph, plus the Go runtime and standard library and, because CGO is enabled for SQLite support, the SQLite amalgamation.

Until now make package copied the source LICENSE and NOTICE verbatim into those packages, where the only third-party component listed is the Greenplum-derived code. That describes neither the 53 Go modules linked into the binaries nor the NOTICE files that eight of them ship, which the Apache License 2.0 requires us to propagate in section 4(d).

Add the -binary variants, following the convention used by Apache Spark, Apache Kafka and apache/cloudberry#1994:

  LICENSE-binary   -> installed as LICENSE
  NOTICE-binary    -> installed as NOTICE
  licenses-binary/ -> installed as licenses/

They are generated by scripts/generate-binary-license.sh rather than maintained by hand. The script resolves the modules actually linked into each shipped binary on each released platform, so test-only dependencies such as Ginkgo and Gomega are left out, while platform-gated modules that appear only on Linux are included. A dependency bump that changes the inventory is caught by the new binary-license-check CI job, which runs the script with --check.

The reproduced license texts carry their own upstream copyright notices and must not be given ASF headers, so they are excluded from the RAT scan.

Verified against the actual artifacts: building the packages on Linux and reading the module list back out of the six shipped binaries with go version -m matches LICENSE-binary exactly, module for module and version for version.

Backpatch-through: REL_2_STABLE

closes: #ISSUE_Number

---

Change logs

Describe your change clearly, including what problem is being solved or what document is being added or updated.

Contributor's checklist

Here are some reminders before you submit your pull request:

• Make sure that your Pull Request has a clear title and commit message. You can take the Git commit template as a reference.
• Learn the code contribution and doc contribution guides for better collaboration.
• Make sure that CICD workflow is successful.
• List your communications in the GitHub Issues or Discussions (if has or needed).
• Feel free to ask for the cloudberry committers or other people to help review and approve.