Add a timezone-aware datetime GraphQL scalar type: DateTimeTz

[obi1kenobi]

Since #827 merged, we don't have a way to represent timezone-aware datetimes. For this, I propose adding a new scalar type: scalar DateTimeTz, Python name GraphQLDateTimeTz.

A few guidelines I'd like to propose:

• Outputting a field of type DateTimeTz is guaranteed to produce a timezone-aware result.
• Runtime arguments of type DateTimeTz are required to contain timezone information.
• Its serialization as a string must always contain either an explicit +HH:mm suffix or the simple suffix Z which is equivalent to +00:00. Other suffixes, such as +HH, +H, America/New_York etc. are explicitly not permitted and unsupported.
• When auto-generating schemas, if a datetime type is explicitly known to carry timezone information (for example, TIMESTAMPTZ in many SQL flavors), it must be represented as DateTimeTz in the auto-generated schema.
• When auto-generating schemas, if it is uncertain whether a datetime type carries timezone information or not, it must be represented as DateTime (i.e. timezone-naive) and a warning must be emitted about the uncertainty. This warning must provide sufficient information to the user so that they are able to manually resolve the issue by explicitly configuring the field in question to appear as timezone-aware or naive.

[pmantica1]

This all sounds good to me. I'd like to mention a couple of points in support of this:
3. I think that the guideline you described here sticks completely with ISO standard and that makes sense to me. Sticking to the ISO standard makes the documentation and code simpler.
5. We already have some functionality to support this. We could tell the user to use class_to_field_type_overrides in get_sqlalchemy_schema_info and get_graphql_schema_from_orientdb_schema_data to override the type in the GraphQL schema.

[obi1kenobi]

3. I think that the guideline you described here sticks completely with ISO standard and that makes sense to me. Sticking to the ISO standard makes the documentation and code simpler.

Yes, exactly. And specifically, this is narrowing the ISO 8601 standard, which is huge — we don't have the resources to implement or support the whole thing.

5. We already have some functionality to support this. We could tell the user to use class_to_field_type_overrides in get_sqlalchemy_schema_info and get_graphql_schema_from_orientdb_schema_data to override the type in the GraphQL schema.

Yes — I just wanted to make sure we don't frame the guidelines I proposed in terms of existing implementations or existing backend implementations. I'm fine with using existing code to achieve these goals.