Auth/Actions: Allow defining bool expression checks in action permissions

### Is your proposal related to a problem?

Motivation: We often find ourselves making queries to the database in the beginning of almost every action for verifying things like:
- Checking whether user belongs to a desirable category/bucket/cohort.
- Checking whether user has the right to modify an entity (ex: is the current user author of the article they're trying to mutate through an action).

### Describe the solution you'd like

Hasura to allow defining action permissions based on bool checks built from data in the database, action arguments and session variables. This way, we can avoid writing a lot of repitetive validation by hand. Some sample solutions:

- Checking whether a user is allowed to use a feature. This can be achieved by a bool expression:

```
{
"_exists": {
"allowed_users": {
"id": {
"_eq": "x-hasura-user-id"
}
}
}
}
```

- Proceed with execution only if user is the author of an article. This can be achieved by a bool expression:

```
{
"_exists": {
"articles": {
"id": {
"_eq": "$action-args.article_id"
},
"author_id": {
"_eq": "x-hasura-user-id"
}
}
}
}
```

### Error definition

Since actions deal with custom business logic, it's important to allow defining custom errors (or error codes) about why the action invocation has failed. Most ideally, I'd like to configure this while defining permissions. Suggested solution:

1. Allow defining multiple checks per role permission
2. For each check, accept an error message and/or error-code
3. Throw this error-message as a part of GraphQL error message and add the code to the extensions

I think this, combined with REST connectors would really be a big step towards improving DX in actions because.

### Describe alternatives you've considered

Writing these permission rules by hand.

### If the feature is approved, would you be willing to submit a PR?
No.

Start by tracing the existing action permission flow and action invocation error handling, then review how REST connectors fit into actions. Done means permissions can express database, action-argument, and session-variable checks, support multiple checks with custom messages or error codes, and expose failures through GraphQL errors.

Written by the indexing model from the issue text.