chore: rename project from c2pa-c to c2pa-cpp

[gpeacock]

Summary

• Updates the CMake project name from c2pa-c to c2pa-cpp (the derived ${c2pa-c_SOURCE_DIR} variables in src/ and tests/ CMakeLists fix automatically)
• Updates all GitHub repo URLs from contentauth/c2pa-c to contentauth/c2pa-cpp
• Updates all GitHub Pages doc URLs from contentauth.github.io/c2pa-c/ to contentauth.github.io/c2pa-cpp/
• Updates Doxyfile project name and brief
• Updates comment strings in scripts/amalgamate.cmake
• Updates ci-cd/amalgam-build.md title and subdirectory reference

What is intentionally NOT changed

• libc2pa_c — the native shared library name (exposes the low-level C API, stays as-is)
• c2pa-c-ffi — the Rust FFI package name (lives in a separate repo)
• c2pa_cpp — the C++ CMake target name (already correct; this rename brings the repo name into alignment with it)
• GitHub Actions workflows (contain no repo-name references)

Pre-merge checklist

• Merge this PR to main
• Rename the repo on GitHub: Settings → General → Repository name → c2pa-cpp
• Redeploy GitHub Pages docs (the Pages URL will change; the redirect does not cover GitHub Pages)
• Update the CAI documentation website (opensource.contentauthenticity.org/docs/c2pa-c slug)
• Update local git remotes: git remote set-url origin https://github.com/contentauth/c2pa-cpp.git

Made with Cursor

[ale-adobe]

LGTM! Makes more sense now. 😄

[tmathern]

Ok for the code change, but what I would do is create a new c2pa-cpp repo.
Move this code there.
Archive c2pa-c.
Point people to c2pa-cpp.

So 0 downstream build would break immediately, and people would have to switch when they want updates.
(There are ways to keep the git history).

Or is there any reason to rename this instead of archiving and creating a new one for c2pa-cpp?

[scouten-adobe]

Yay, happy to see this change!

[scouten-adobe]

@tmathern in my experience, GitHub is actually very good at tracking project renames (i.e. forwarding requests aimed at the old repo name to the new one), so I expect very few of the kinds of problems you are expecting will happen in practice.

If we do archive and restart as you propose, this will actually cause many new problems, to wit:

• existing commits that reference PR and issue numbers will collide with newly-assigned PR and issue numbers in the new repo
• all PRs and issues filed against the old repo would have to be re-constructed in the new.

I'm opposed to that approach for that reason.

[tmathern]

@tmathern in my experience, GitHub is actually very good at tracking project renames (i.e. forwarding requests aimed at the old repo name to the new one), so I expect very few of the kinds of problems you are expecting will happen in practice.

If we do archive and restart as you propose, this will actually cause many new problems, to wit:

• existing commits that reference PR and issue numbers will collide with newly-assigned PR and issue numbers in the new repo
• all PRs and issues filed against the old repo would have to be re-constructed in the new.

I'm opposed to that approach for that reason.

There are repos who pull in this repo through cmakelist. At the very least then, announce it once this is done, and submit the PRs to update the repos when you know they used it.