Create a `CloudEvent` type into azcore, for use with messaging SDKs

[richardpark-msft]

The CloudEvent type is used heavily in the upcoming EventGrid SDK for Go, with potential future integration into other messaging SDKs like webpubsub, azeventhubs, and azservicebus.

The basic type is pretty simple:

type CloudEvent struct {
  Data any               // JSON serializable data

  ID *string

  // defaults to "1.0" (TODO: unsure if empty string is considered a valid version)
  SpecVersion *string
}

The ID and SpecVersion fields will get default values

Some other bits I need to flesh out:

1. CloudEvent has a concept of 'extensions', which allow you to plug in properties that are serialized at the root of the object.
2. The actual model type has a property called data_base64, but the libraries all hide it. It's used internally for transport, but not exposed to the user directly.

[jhendrixMSFT]

Does this really belong in azcore? To date we've avoided having service-specific content in it.

CC @JeffreyRichter

[richardpark-msft]

Does this really belong in azcore? To date we've avoided having service-specific content in it.

CC @JeffreyRichter

I was just updating the text, but I believe so. It's used by Event Grid, and it was also going to be used by Service Bus and Event Hubs, so shared across several SDKs.

Considering all the other languages already prepped for this I couldn't think of a reason not to do it.

[JeffreyRichter]

CloudEvents are an industry standard: https://github.com/cloudevents/spec
We would expect ALL messaging services (servicebus, etc.) to use them.
It is basically a dumb type that only has (Un)MarhsalJSON methods on it.
I'm OK with it in azcore. You could imagine customers using the azqueue package leveraging CloudEvents for their message structure.
I guess the question is how much convenience are we providing by having it in azcore?

[jhendrixMSFT]

I see. Would this go in azcore or a sub package e.g. azcore/messaging? My preference is the latter but could be convinced otherwise.

[richardpark-msft]

One option we have is that we can always add an alias later if we move it to core. So then we could create a messaging sub-package.

With that said, it's probably not worth making a new public common module for just the one type.