Capturing undeclared fields

Hello,

I am currently working on a JSON binding implementation in Apache SIS (https://sis.apache.org/) of the Coverage-JSON specification (https://github.com/opengeospatial/CoverageJSON) .

In the specification, several extensions are possible as described in chapter 9.6 (https://opengeospatial.github.io/ogcna-auto-review/21-069.html#_56b929af-e36d-4994-ac3b-29bcf86f4728)
```
9.7. Extensions

A CoverageJSON document can be extended with custom members and types in a robust and interoperable way. For that, it makes use of absolute URIs and compact URIs (prefix:suffix) in order to avoid conflicts with other extensions and future versions of the format. A central registry of compact URI prefixes is provided which anyone can extend and which is a simple mapping from compact URI prefix to namespace URI in order to avoid collisions with other extensions that are based on compact URIs as well. Extensions that do not follow this approach MAY use simple names instead of absolute or compact URIs but have to accept the consequence of the document being less interoperable and future-proof. In certain use cases this is not an issue and may be a preferred solution for simplicity reasons, for example, if such CoverageJSON documents are only used internally and are not meant to be shared to a wider audience.
```

Problem is, I could not find a way to catch those additional attributes, as in Jackson (@JsonAnyGetter) or Johnzon (@JohnzonAny)

Maybe I just missed it ? is there an example somewhere ?

If not, here is what I would like to see one day maybe :

As in Johnzon or Jackson :
```
@YassonUndeclared
public final Map any = new LinkedHashMap<>();
```

Or maybe with some changes in jsonb specification ?
```
@JsonbProperty("*")
public final Map any = new LinkedHashMap<>();
```

**Version**
Yasson 3.0.3

The issue names no source files, tests, or entry points. Start by locating Yasson's handling of undeclared JSON members and compare the requested behavior with the Jackson and Johnzon examples; done would require a decided API design, documented behavior, and tests for capturing additional fields.

Written by the indexing model from the issue text.