fix: scope the formit permission to its own policy template

[Ibochkarev]

permissions.resolver.php creates the formit and formit_encryptions modAccessPermission bits only on templates listed in each permission's templates key (AdministratorTemplate), which is correct.

The second loop, which writes the actual true/false value into every modAccessPolicy's data blob, never checked that same templates restriction. Any permission without an explicit policies allowlist (formit) fell into the unconditional $data[$permission['name']] = true branch for every policy in the system, including ones built from unrelated templates like ElementTemplate. That's the "10 of 9 active policies" the issue describes.

Reproduced both the bug and the fix with a standalone script stubbing xPDO's getCollection()/getObject()/newObject() against the resolver's actual logic: with a policy on AdministratorTemplate and one on an unrelated ElementTemplate, the original code added formit => true to both; this fix only adds it to the AdministratorTemplate one, leaving the unrelated policy's data untouched.

Fix: build a template id → name lookup while walking the templates in the first loop, then skip a policy in the second loop whenever its template isn't in the permission's templates list.

See #246 for the broader question of whether FormIt should own its own policy template instead of piggybacking on AdministratorTemplate. This PR doesn't attempt that redesign, it just stops the current approach from leaking into policies it has no business touching.

Fixes #272