feat: Add 'UTC-NOW' support to DateTime

[ChrisBQu]

This PR makes a small adjustment to the DateTime scalar, to allow use of a literal value, now which will be parsed into the current time at the time of resolution.

This will, for example, allow us to do a query like the following, over on the Defradb side of things:

defradb client schema add '
 type ObjectWithTimestamp {
   timestamp: DateTime
 }
'

defradb client query '
 mutation {
     create_ObjectWithTimestamp(input: {timestamp: UTC-NOW}) {
         _docID
     }
 }
 `

Notice that now is not a string, but is a literal that gets handled.

This PR is proposed as the first step in resolving this issue over on Defradb:

sourcenetwork/defradb#4152

My intention is to add integration tests of this functionality on the Defradb side of things.

[getify]

I like this feature. Glad to see it being added.

@fredcarle @jsimnz I think we had a DevEx call a couple of weeks ago where we discussed the idea of having certain keywords follow the ALLCAPS style of naming (leaning into how SQL does it), instead of the _ prefixing.

If that still holds, I might suggest it should be NOW here instead of now? Alternatively, we could just make the check case-insensitive?

[AndrewSisley]

Got a couple of comments that I'd like sorted before merge, and the following thought:

thought: This does feel a little incorrect, as the DateTime is a scalar, and now is essentially a function. I cannot think of anything that will break for sure right now, including ORMs though, as I believe the GQL types are only ever input-types. I have a bit of a worry that this might result in more complicated type-mapping for ORMs, especially for typed langs that don't support union types.

The flip side is, this feature is otherwise really nice, and applies to basically everywhere without us having to worry about it or do much coding :)

[AndrewSisley]

suggestion: "now" is ambiguous IMO, "utc-now" would be clearer I think, and allows us to add other variants more cleanly without changing this definition.

[AndrewSisley]

todo: Github wouldn't let me comment on un-edited lines - please document this in the Description a few lines up, please make sure you note the time zone or lack-of, and that it is evaluated server-side as that can be a bit ambiguous when using some clients.

[ChrisBQu]

Got a couple of comments that I'd like sorted before merge, and the following thought:

thought: This does feel a little incorrect, as the DateTime is a scalar, and now is essentially a function. I cannot think of anything that will break for sure right now, including ORMs though, as I believe the GQL types are only ever input-types. I have a bit of a worry that this might result in more complicated type-mapping for ORMs, especially for typed langs that don't support union types.

The flip side is, this feature is otherwise really nice, and applies to basically everywhere without us having to worry about it or do much coding :)

Thanks for the input. I won't rush to merge it. I think maybe this issue, as well as exactly what to call the field, could be good to discuss at the next standup.