rfc: improvements to inherited roles

Currently, we only support deriving 'table-select' permissions (select permissions on a table) for an inherited role, i.e, if the parent roles of an inherited role have any mutation/function/ remote-schema permissions, we ignore them.

The reason for this being that we do not know how to 'derive' the rest of the permissions in a general case, mostly because of the 'presets' feature. For example, say an inherited role `owner` derives from `user` and `editor` roles, but `user` and `editor` have different presets on some column `c` of table `t` for update permissions - there is no reason for us to pick one over the other. However, ignoring non table-select permissions because we cannot derive permissions in a general case makes inherited roles less useful

## 1: Derive rest of the permissions for simpler cases

Instead of failing early, we should instead try our best to derive all permissions at least for simpler use cases where there is no scope for conflicting definitions. One simple improvement that we can add is to derive a permission if it same across all the parent roles, or if only one of the parent roles define it. We can keep relaxing this constraint over time as we build the logic to handle more complex permissions.

## 2: Unify roles and inherited roles

While (1) definitely improves the current situation, we'll need an escape hatch for when we fail to derive some permission. Again, a simple approach that we can take here is to let the user define this permission. For example, in the above case, our user would define the update permission for `owner` role on table `t`.

Currently, we disallow explicit permission definitions for inherited roles. We should remove this restriction. In fact, we can even unify 'roles' and 'inherited roles'. Our current notion of a role is nothing but an inherited role with zero parent roles. As long as we disallow cycles, we should be fine.

## 3: Keep extending the domain of permissions that can be merged

While in general case, we cannot define the merge semantics for permissions with presets, we can definitely try and handle special cases where there are no presets defined.

TODO: This section has to be expanded with these special cases and how they can be handled.

The issue names no files, tests, or entry points. Start by locating inherited-role permission derivation and validation, then trace how permissions and parent roles are represented; done would cover the stated simple merge cases, explicit permissions, role unification, and cycle prevention with corresponding tests.

Written by the indexing model from the issue text.