feat(iam): add usermanagement and accessmanagement CLI commands

[jt-nr]

Adds two new top-level commands that expose New Relic user and access management via the CLI.

Command structure

The command hierarchy mirrors the two distinct sections of the New Relic Administration UI — User Management and Access Management — rather than the underlying SDK package layout. This gives CLI users a mental model consistent with the UI and the product documentation, regardless of how the NerdGraph schema is organized internally.

usermanagement (actor.organization.userManagement.*):

• users get/create/update/delete
• groups get/create/update/delete
• groups members add/remove
• auth-domains get

accessmanagement:

• grants get/create/revoke
• roles get
• permissions get

SDK usage in accessmanagement

The Access Management UI makes NerdGraph calls to two different schema roots on the same page: actor.organization.authorizationManagement.* for grant mutations, and customerAdministration.* for reads (grants get, roles get, permissions get). We followed the same split here so CLI behavior matches what users see in the UI:

• grants create/revoke → authorizationManagement SDK
• grants get, roles get, permissions get → customerAdministration SDK

roles get uses customerAdministration specifically because it supports richer filtering (name contains, groupId) compared to the equivalent authorizationManagement method.

Naming

• "grants create/revoke" follows the CRUD convention used elsewhere in the CLI rather than the SDK's GrantAccess/RevokeAccess naming.
• Flag names use camelCase to match existing CLI conventions (--authDomainId, --groupId, --userId, --roleId).

Includes per-package READMEs with command reference, flag docs, example responses, jq recipes, and an end-to-end workflow that spans both commands — since the natural flow is to create users/groups in usermanagement and then assign access in accessmanagement.

[CLAassistant]

All committers have signed the CLA.

[jt-nr]

Note on the E2E failures: these are expected for fork PRs. The e2e.yml workflow requires repository secrets (New Relic API keys, account IDs, cloud credentials) to provision agents on real infrastructure — GitHub doesn't pass those to workflows triggered from forks. No code changes needed. A maintainer will need to trigger E2E after review.