Implement organization membership resources

[displague]

The Equinix Metal API offers organization member endpoints.

Organizations have members:

• GET /organization/{id}/members

New members can be added:

• POST /organization/{id}/invitations
• Can these invitations be updated or deleted by the org owner?

Memberships can be deleted:

• DELETE /memberships/{id}

Memberships can be updated:

• PUT /memberships/{id} (role can be changed. Is project_ids available but undocumented for changes to collaborator or for changing collaborator project_ids? Network Inspect the Portal.)

Organization members can be assigned projects and roles on creation.

Roles include admin, collaborator, and billing. Additional roles may be added later.

What does this look like:

resource "metal_organization_member" "marques" {
  organization_id = "" # required
  roles = ["admin", "collaborator", "billing"] # required.
  # What does it mean to have multiple roles?

  invitation_message = ""

  # project_ids is included in the invitation, but is also returned in the organization membership response
  project_ids = ["", ""] # only used/needed for 'collaborators'

  # user is returned but we don't need to include all of that in this resource
  # presenting user.email as user_email fits our TF pattern in other resources.
  # user_email would act as the "invitee" in the invitation field.
  # Does this create a problem if the invitee email differs from the primary user email?
  user_email = "" # required

  # id - memberships have ids
}

The single result data source would query on user_email and organization_id, or by id / membership_id.

data "metal_organization_member" "member" {
  # both of:
  # organization_id
  # user_email = "email@example.com"

  # or:  
  # membership_id
}

The attributes would include roles, project_ids, user_email, organization_id, membership_id. Should we include other user properties, or can we offer a metal_user data source to query users?
Can organization or project members fetch user records for fellow team members?

Should we also provide a multiple resource datasource:

data "metal_organization_members" "member_list" {
  # organization_id -- optional with project_id, should this default to some organization like metal_projects does?
  # project_id -- if specified, we can use /projects/{id}/memberships instead of /organizations/{id}/members
  # user_email_filter = "*@gmail.com" ? should we offer a filter?
}

[displague]

We should not validate the "role". We can use documentation to suggest the roles that are known today, but when future roles are added the user should not need to update Terraform to take advantage of them. Let the API handle role validation.

[displague]

Depends on equinixmetal-archive/packngo#346