Override "select filter permissions" from original tables with custom functions

### Is your proposal related to a problem?

On our app, we have a global "projects" table, where the permission are the following simple one:
- Does the user is a member of the project ? If it is, allow access.

This table has a bunch of relations to other tables, some with the same access conditions, some with a more restricted one.

However, in some cases where someone, administrator of an org, want to see an overview dashboard of all the projects his org members are in, we would want to "bypass" the projects filter permissions, and apply a heavier to compute access permission logic, but still allowing the API to work with "projects". Allowing the user to access "basics fields" on it, and making the "relations with details" still protected (since for instance a document on a project check if your a project member, the administrator will be able to see the "name" of a project (directly on the project table) but will have an empty list of "documents" for it, since he's not a member of this project).

Digging into the repo I found this: https://github.com/hasura/graphql-engine/blob/71ae144aa623c156064ffe21eb38020ccf315a7a/rfcs/function-permissions.md#L77

So it seems that the solution has been already reflected upon and for the part which is:

```
1. Ability to override the `filter` of the select permission defined on
functions returning table types.
```

I want to put this case in:

- When you want to use "custom functions" queries as a graph entry point with heavy custom permissions logics, less restrictive than the common ones on a table.

### Describe the solution you'd like

Something like this in the metadata:

```yaml
function:
name: get_user_project_org_overview
schema: public
configuration:
custom_root_fields: {}
session_argument: hasura_session
permissions:
- role: user
description:
select_permissions:
- permission:
filter: {}
```

This would override the "original" select permissions for the user role and apply the new ones (which in this cases are empty) to the select query. Allowing the "get_user_project_org_overview" to handle permissions access and still re-use the common type of "project" in terms of graphql API.

### Describe alternatives you've considered

As for now, I don't see anything to achieve what I want except:

1. Create a view like so `CREATE VIEW v_projects_overview AS SELECT * FROM projects;`
2. Re-apply the relations/permissions rules on the newly created view.

This come with 2 major downside:
1. A "view" polute the database for no other purpose than "recreating a type" for the graphql api.
3. No possibilities to re-use the project type, meaning that if you want to add a new field on it, you must think about updating your custom function as well

### If the feature is approved, would you be willing to submit a PR?
Never done haskell, probably not the best idea 😂