Support all utility OpenApi annotations on fields

[dzikoysk]

Context

Most of the property attributes work fine and make sense on fields, but don't currently support being put there. This fixes that limitation, which is useful when using @OpenApiByFields. (My immediate use case is OpenApiDescription, but the others seemed useful too.)

~ Reported by @maths22 in #216

---

Feedback wanted

I personally feel like most of the use cases should be absolutely fine with our current approach, but I'm open for feedback from other users that for some reason are forced to use fields.

As a straightforward solution, it is possible to cover this with @CustomAnnotation, but if we'll notice it is a frequent issue, I think we could support it in the core library.

[Petersoj]

One use case for allowing the @OpenApiRequired annotation on a field would be in the following situation that I'm currently running into: I want to mark a Lombok POJO field as required in the generated spec, but I don't want to use @NotNull on the field because IntelliJ show warnings about "unnecessary" null checks, when they are in fact necessary because deserializing JSON via Gson (in Java) doesn't enforce @NotNull. I could of course add @SuppressWarnings or disable those warnings in my IDE, but that's not ideal. Additionally, marking my required Lombok POJO fields with @Getter(onMethod = @__({@OpenApiRequired})) looks pretty ugly.
Using a @CustomAnnotation with boolean required() default true; won't work in this case because marking a property as required in the spec means including the property/field name in the required array instead of being attached as a custom JSON key/value on the property/field (as a @CustomAnnotation with a required field would do).