[Feature]: Support role membership options `ADMIN`, `INHERIT`, `SET`

### Is there an existing issue already for this feature request/idea?

- [x] I have searched for an existing issue, and could not find anything. I believe this is a new feature request to be evaluated.

### What problem is this feature going to solve? Why should it be added?

I don't like when changes are made in the database with the personal role, where the applications role should have been used to have the owner set correctly, only because the user was not prompted to "become" another role, because they already had the required permissions inherited.

But I also want to have some roles where the permissions should be granted to every personal role directly.
`inherit` would have to be true for only these roles, but with CNPG I can only set it as a default for the user to be applied to all role memberships.

### Describe the solution you'd like

I'd like to have a new field in the `RoleConfiguration` that holds information about the parent roles the configured role should be added to with additional fields for each membership option as described by the official PostgreSQL documentation.

```yaml
# example taken from documentation https://cloudnative-pg.io/docs/1.28/declarative_role_management
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
spec:
managed:
roles:
- name: dante
ensure: present
comment: Dante Alighieri
login: true
superuser: false
inRoles:
- pg_monitor
- pg_signal_backend
# new field
roleGrants:
- role: my_application_role
inherit: false
admin: false
set: true
```
I am aware that these are the default options for `admin` and `set` - they could be omitted, I only put them here to clarify the schema I have in mind.
For `inherit`, the default is whatever is specified for the user, which would be `true` if not specified otherwise. So with my proposal, you'd be able to override this on a per-role level.

### Describe alternatives you've considered

I considered to manage the grants externally and only use CNPG to set up the cluster, but I think this is a feature that could be useful to others as well.

For the schema I also considered changing the `inRoles` definition to allow for passing the options, but this would be a breaking change to the Cluster CRD. And the new field could not

### Additional context

Looking at the implementation, the role memberships defined in `roleGrants` would not be managed when creating the user, but during `UpdateMembership`. This means if I want my user creation to fail if the role does not exist, I specify the membership in `inRoles`.
But it also means the order of `.spec.managed.roles` does not matter, because they would be created first and only after all of them are present the memberships would be reconciled.

When the same role is specified in both `inRoles` and `roleGrants`, the options specified in `roleGrants` take precedence.

Updating the options is done by simply `GRANT`-ing again with the updated options set. They will be overridden.

I have to adjust the `GetParentRoles` command to return the currently set options as well.

Please let me know your feedback to this.
I'd like to attempt implementing it and we could discuss further implementation details on the PR I'm going to open.

### Backport?

N/A

### Are you willing to actively contribute to this feature?

Yes

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct