Implement decorator to support date serialization format

[markcowl]

• Implement 'dateFormat' decorator that allows choosing 'rfc1123', 'rfc3339', 'rfc7231', and 'unixTimeStamp' date formats
• Update emitters to respect the dateFormat set by the decorator
• Update emitters to set date format rfc7231 in http headers, and rfc3339 in other usages when no dateFormat is provided
• Update documentation to show usage of dateFormat decorator, and default date formats

Per design issue #https://github.com/Azure/cadl-azure/issues/1020

[mikekistler]

Update on this topic. Dates in headers should follow RFC 7231 -- specifically Section 7.1.1.1. This is a more modern and slightly stricter format that RFC 1123, in that a) it requires seconds to be included in the time (seconds is optional in RFC 1123), and b) it requires the time zone to be "GMT" -- no other zones are allowed.

We will be updating the Azure API Guidelines to replace the references to RFC 1123 with RFC 7231.

[lmazuel]

OpenAI has timestamp format (expressed as int right now) that we would need to know be exposed as datetime.

It's unclear at the moment if we should do a cadl-dpg decorator, or expect this issue to be solved.

cc @johanste

[timotheeguerin]

Proposal: https://gist.github.com/timotheeguerin/83869d24730e18013b69674febcb126b

Items from design meeting

Items

Encode:

• Core: check known encoding match their encoding type
• Core: deprecate use @format on bytes. Only for string
• Azure.Core: linting rule banning unknown encoding

Format change:

• Azure.Core: linting rule banning @format
• Azure.Core: add missing scalars(uuid, etc. See what to take from https://github.com/Azure/autorest/blob/main/packages/libs/openapi/src/v3/formats.ts#L1)

Logic for emitter:

• Generated type: use the actual typespec type
• Over the wire type:
  • lookup for @encode decorator
    • if absent use typespec type (or default way of serializing that type)
    • if present respect type provided in @encode