TileJSONExtended implementation

[Perdjesk]

Alternative of #772

Derived from TileJSON specification a tiles-extended.json with cherry-picked (i.e allow list) baremaps metadata fields out of tileset.json configuration file.

// POJO for baremaps-core and baremaps-server (all content is deserialized)
Tileset.class
// POJO strictly following TileJSON specifications for API clients.
TileJSON.class
// POJO following TileJSON with extended fields specific to baremaps
TileJSONExtended.class

In this PR tiles.json is always the TileJSON spec. And tiles-extended.json is only available in dev server. However the following options can be easily decided:

• Whether to provide TileJSONExtended in prod
• Whether to serve TileJSONExtended in place of tiles.json or separately tiles-extended.json

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

No Coverage information
0.0% Duplication

[Perdjesk]

Given some thoughts to it, I would propose the following:

Always expose in the API TileJSONExtended as a separated resource tiles-extended.json as there must be nothing confidential in this file and it should be enforce by review of additions in classes.
Always expose in the API TileJSON as tiles.json.

Pros:

• Remove discrepancies between dev/prod mode.
• Only consume extended version willingly.
• Avoid potential clashes with clients implementations not supporting tiles.json with additional properties.