Create quarkus hal extension for resteasy and reactive

[Sgitario]

The quarkus-hal is a new extension that supports both resteasy and resteasy reactive.

• New extension quarkus-hal (mostly copied from quarkus rest data panache). The only change I made is that before, in Rest Data Panache, the jsonb and jackson serializers were serializing the entity into hal and also resolving the hal links. Now, the jsonb and jackson serializers are only serializing the entity that should have been previously populated with the hal links (this is done via server filters in resteasy classic and resteasy reactive).
• Documented in Quarkus Restasy Reactive and Quarkus Resteasy guides

This is a follow-up action from #25217 (comment)

[geoand]

Thanks a lot @Sgitario.

I'll have a look next week.

[Sgitario]

A possible solution to not add breaking changes in Resteasy Classic is to not remove the auto-generated hal resources in quarkus-hibernate-rest-data-panache. Therefore, this dependency would only use the hal API from quarkus-hal and nothing else. The disadvantage of this is that we would be still duplicating the resources implementations for JSON and hal, and duplicating the hal JSON serializers in quarkus-hal and in quarkus-hibernate-rest-data-panache (as the serializers in quarkus-hibernate-rest-data-panache are also gathering the HAL links).

And another solution could be to change quarkus-hibernate-orm-rest-data-panache to use quarkus-resteas-reactive by default, so we could add quarkus-resteasy-reactive-links. Of course, we'd need to document how to keep using resteasy classic.

[geoand]

@Sgitario perhaps the description in #20874 will give you more insight into why things have been done the way they have

[Sgitario]

I had to explicitly add this dependency, I guess because we had to use the -deployment version. However, this is not necessary to be added when using quarkus-hibernate-orm-rest-data-panache (there are tests to verify this).

[Sgitario]

I had to explicitly add this dependency, I guess because we had to use the -deployment version. However, this is not necessary to be added when using quarkus-spring-data-rest (there are tests to verify this).

[Sgitario]

@Sgitario perhaps the description in #20874 will give you more insight into why things have been done the way they have

PR updated

[geoand]

This is great work, thanks!

I've just added a few comments

[geoand]

We can leave addressing this for a following PR, but in RESTEasy Reactive we generally try to avoid performing reflection as much as possible as it has a negative effect on both the execution speed and memory consumption. This data is generally available at build time, so we try to leverage it as much as possible.

[Sgitario]

I've removed the second part of this method. For the first part, we can do it in the next iteration.

[geoand]

So the second part was not needed?

[Sgitario]

No, it wasn't needed at all.

[rsvoboda]

@gsmet this wasn't mentioned in https://quarkus.io/blog/quarkus-2-10-0-final-released/