Add created_at and updated_at to alerts in alerting

[FrankHassanabad]

Describe the feature:
Add created_at and updated_at to alerts in alerting.

Describe a specific use case for the feature:
When users are writing UI's they need to see when an alert was created and when it was last updated.

See this older saved object issue where created_at was proposed:
#9376

saved objects already have a updated_at, it just needs to flow down to the alerts infrastructure.

[elasticmachine]

Pinging @elastic/kibana-stack-services (Team:Stack Services)

[gmmorris]

This has now been implemented but I was a little torn on how to go about it, so here are a couple of thoughts.

I initially added two properties to the SavedObject - updatedAt and createdAt.
createdAt is set at creation and untouched after. updatedAt is changed on every subsequent update (be it using update, mute, unmute etc.).
The reason I did this rather than use the existing updated_at property that the SavedObject Client already provides was that we so internal updates using that client throughout the creation process, meaning that field would be set on creation and so if I create an Alert, it'll immediately be marked as both created and updated by me, which felt weird.

I then gave it some more thought and realised that that is technically correct, and more importantly, using the SavedObjects field would reflect when the Alert is actually updated, meaning if I do something that has the side effect of updating the SavedObject - that'll be reflected in the Alerting updatedAt field, even if I don't use the update api directly, and that felt like a safer choice.

So the final implementation uses the SavedObjects updated_at property, but it is exposed on API calls as updatedAt along side createdAt.
(Using CamelCase as all other Alerting properties are CamelCased... and I do acknowledge the irony of writing CamelCase in PascalCase)