Fix unautoloadable FacebookAds classes in capi-param-builder (PSR-4 violation breaking php-business-sdk)

Summary: GitHub issue facebook/capi-param-builder#36: FacebookAds\PII_DATA_TYPE is not autoloadable in 1.3.1, which breaks facebook/php-business-sdk 25.0.2 — UserData::normalize() calls FacebookAds\PII_DATA_TYPE::EMAIL, and any server-side Conversions API event fatals with Class "FacebookAds\PII_DATA_TYPE" not found.

Root cause: the package’s only autoload rule is psr-4: { "FacebookAds\\": "src/" }, but PII_DATA_TYPE (and in fact all 15 classes under src/model/, src/util/, src/piiUtil/) declare the flat namespace FacebookAds; while living in subdirectories. Under PSR-4, FacebookAds\PII_DATA_TYPE must resolve to src/PII_DATA_TYPE.php; Composer never looks in src/model/Constants.php, so class_exists('FacebookAds\PII_DATA_TYPE') returns false. The package itself only works today via manual require_once chains, but a downstream consumer that references the class through Composer autoloading (like the SDK) fatals.

Fix: add a classmap autoload entry for the three subdirectories alongside the existing PSR-4 map. Composer’s classmap maps a class to its file by scanning declarations regardless of filename or directory, so FacebookAds\PII_DATA_TYPE and the other 14 subdirectory classes become autoloadable while every fully-qualified class name stays exactly as-is (important: the SDK depends on the flat FacebookAds\PII_DATA_TYPE FQN, so renaming/re-namespacing is not an option). This is the maintainer-suggested fix from the issue and requires no file moves or namespace changes. Also bumped the package version 1.3.1 -> 1.3.2 so the fix ships as a new release.

---

Differential Revision: D112249764

fbshipit-source-id: 7f5b758a5f93683daa182bc1fd7aecfec869233e