Improve documentation of nullability on LoggingEvent interface

[hermannm]

I recently worked with the SLF4J LoggingEvent interface, and found myself having to dig through the DefaultLoggingEvent implementation to see which methods on LoggingEvent could actually return null. I saw that there is an existing docstring documenting the nullability of LoggingEvent.getMarkers(), but none for the other methods. I figured it would be useful to document this on all methods, to make the interface contract clearer.

The existing LoggingEvent.getMarkers() docstring duplicated its text in the main doc and in @return. This seemed redundant to me, but if you prefer this format I'll change over to it.

I figured that for a small change like this it would be easiest to submit a PR directly, so I didn't go through the mailing list/bug report. But I'll do that if you prefer strictly following the contributor guidelines.

[ppkarwasz]

It would be probably useful to annotate SLF4J with JSpecify. Unlike all the previous nullability annotations, JSpecify is actually supported by a long list of vendors and it is becoming the de facto standard.
Spring also decided to migrate to JSpecify (see spring-projects/spring-framework#28797).

[hermannm]

It would be probably useful to annotate SLF4J with JSpecify. Unlike all the previous nullability annotations, JSpecify is actually supported by a long list of vendors and it is becoming the de facto standard. Spring also decided to migrate to JSpecify (see spring-projects/spring-framework#28797).

Agreed that JSpecify would be better! But adopting that seems like a greater effort, that should be a project-wide decision (correct me if I'm wrong). Until we decide to adopt JSpecify, I thought it would be useful to at least document nullability like this.