new event API for common fields

this is a reboot of #4327, and like #4326, as we are closing in 5.0 and would like to see if there is any traction to this proposal.
#### Event#message
- After discussing the `Event#message` idea in #4327, since this is not a required field, I drop this proposal.
#### Event#tags
- We already have prior art in introducing the `Event#tag` method which makes sure the `tags` field is a deduplicated arry of tags. In that respect, the `tags` field is a first class citizen.
- I suggest we also add te `Event#tags` method to return the list of tags instead of going through the `event.get("tags")` field reference.
- I also suggest that, just like `@timestamp`, setting a value using the `tags` field using `event.set("tags", ...)` should be validated to make sure the `tags` field is always a list of deduplicated tags.

Start by reviewing the existing Event#tag method and the event.set("tags", ...) path described in the issue. Determine how a tags accessor and validation would fit the current Event API; done means the proposal is implemented consistently with deduplicated tag behavior and covered by the relevant existing tests.

Written by the indexing model from the issue text.