Using X-Hasura-User-Id with a UUID in _contains permissions does not work

Doing something like the below, where `member_ids` is a jsonb array on a view:

```yaml
filter:
_or:
- member_ids:
_contains: X-Hasura-User-Id
- assignee_id:
_eq: X-Hasura-User-Id
```

does not work. Specifically I'm getting the following error back:

```json
{
"errors": [
{
"extensions": {
"path": "$",
"code": "data-exception"
},
"message": "invalid input syntax for type json"
}
]
}
```

Which appears to be returned directly from Postgres. The query Hasura appears to be generating contains the following snippet:

```sql
WHERE ((((\"public\".\"project_tasks\".\"member_ids\") @> ((($1->>'x-hasura-user-id'))::jsonb)) OR (((\"public\".\"project_tasks\".\"assignee_id\") = ((($1->>'x-hasura-user-id'))::uuid))
```

So it is correctly trying to grab the session variable, but then I'm assuming it's failing to correctly wrap the UUID in quotes. If I manually do this with a UUID I already have, `where member_ids @> (('6bda2a0f-8ecd-4469-9e04-81c29f9accf3'))::jsonb`, then it also fails. Note that if I instead call `where member_ids @> ((public.gen_random_uuid()::text))::jsonb`, then this seems to work correctly.

It does appear to work just fine if someone is using integer IDs in `X-Hasura-User-Id`, but I think using UUIDs is fairly common at this point, so probably should be supported.

I think the actual issue is that `::jsonb` is being used, rather then `to_jsonb`, which does a better job converting arbitrary types to jsonb. If I do `where member_ids @> ((to_jsonb('6bda2a0f-8ecd-4469-9e04-81c29f9accf3'::text)))`, then everything works just fine. I think this is a more robust solution in general when working with `_contains`, so maybe that's the switch that should be made?

This is also related to #4817, but I think is somewhat separate. That issue seems to be about using session variables inside more complex column expressions, where the session variables aren't getting replaced in the larger structure, which isn't quite the same issue as here.

I've confirmed this is occurring in 1.3.0, 1.3.3, and 2.0.0-alpha.8