rfc: Range & Multirange types

### Is your proposal related to a problem?

Ranges & Multiranges are parsed inconveniently likewise other specific data type
Related to #1082

### Describe the solution you'd like

Ranges should compile into GraphQL json-serializable input\output types with the following structure, using tstzrange as an example
```graphql
type tstz_range_bound {
inclusive: boolean!
value: timestamptz ## Null indicates infinity
}

type tstz_range {
upper: range_bound!
lower: range_bound!
}

## multirange example
type table {
tstz_multirange: [range!]!
}

input tstz_range_bound_input {
inclusive: boolean!
value: timestamptz ## Null indicates infinity
}

input tstz_range_input {
upper: tstz_range_bound_input!
lower: tstz_range_bound_input!
}

input tstz_range_comparison_bool_exp {
_cnt_range: tstz_range_input! ## @>
_ncnt_range: tstz_range_input! ## @>
_cnt: timestamptz! ## @>
_ncnt: timestamptz! ## @>
## ...so on
}

input tstz_multirange_comparison_bool_exp {
_cnt_range: [tstz_range_input!]! ## @>
_ncnt_range: [tstz_range_input!]! ## @>
_cnt: timestamptz! ## @>
_ncnt: timestamptz! ## @>
## ...so on
}

## and update timestamptz
input timestamptz_comparison_exp {
_in_range: [tstz_range_input!]! ## <@
_nin_range: [tstz_range_input!]! ## <@
## ...so on
}
```
Such or similar fieldnames are recommended to use so there is no camelCase\snake_case controversy

### Describe alternatives you've considered

Write views per table containing range\multirange columns that would return JSON or columns named like `start_end`

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