Support configuration-as-code for nomad acl role/bindingrule/auth-method

### Proposal
The api of `nomad acl role` and `binding-rule` and `auth-method` all have similar methods:

```
Subcommands:
create Create a new ACL auth method
delete Delete an existing ACL auth method
info Fetch information on an existing ACL auth method
list List ACL auth methods
update Update an existing ACL auth method
```

The commands however can't be easily stored in "configuration-as-code" because they are stateful - `create` creates a new thing, and then you have to `list` that thing to get an ID, and then you can `update` that thing to _change_ it. You can't "upsert".

My proposal is to, instead of `create`+`update`, just provide a `write` method the same as `vault write`, that will just load all the stuff, including the unique name of the resource, from a json. Or simpler, for example support `update -or-insert` that will update the resource if exists but if the resource does not exist, it will just be created. For example:

```
# myrole.role.json
{
"name": "myrole",
"description": "my description",
"policy": "my policy"
}

# shell
nomad acl role write myrole.role.json

# mybinding.binding-rule.json
{
"name": "mybinding",
"bind-name": "etc.",
"etc.
}

# shell
nomad acl binding-rule write mybinding.binding-rule.json
```

Or for example `-upsert -by-name` in all the APIs:

```
nomad acl role update \
-description="acl role for education" \
-policy=education \
-upsert \
-by-name \
education
nomad acl binding-rule update \
-bind-type=role \
-bind-name=education \
-selector="education in list.roles" \
-description="education group" \
-upsert \
-by-name \
mybindingrule
nomad acl auth-method update \
-default=true \
-token-locality=global \
-max-token-ttl="24h" \
-type=OIDC \
-config @acl_auth_method.json \
-upsert \
vault
```

### Use-cases
Managing `update` is a bit hard. Use case is to simplify configuration of roles and binding-rules and auth-methods, so they can be easily serialized and deserialized. Also, unit testing is much simpler.

### Attempted Solutions
Rule is simple - they have a name. But binding-rule and auth-method do not have a name, they can be searched for - they get random ID when created. Currently creating a binding-rule or auth-method is a manual process, then `update` can be stored as configuration-as-code.

And: Thank you for Nomad, it's amazing, and the ACL work great!

Start by locating the CLI entry points for `nomad acl role`, `binding-rule`, and `auth-method`, then compare their existing create and update flows. Clarify whether the intended interface is `write` or upsert-by-name before designing behavior for resources without names. Done should include a consistent configuration-as-code workflow and unit coverage for create-versus-update behavior.

Written by the indexing model from the issue text.