Supporting content negotiation via `Accept`

**Is your feature request related to a problem? Please describe.** Yes. It is currently not possible to correctly support MLT in tile servers because clients do not provide any signal indicating whether they expect MVT or MLT. As a result, servers must guess and typically default to MVT for backwards compatibility. Guessing is bad, we should not guess if we can avoid it. From a tile server perspective, this is effectively a bug: if a client operates in an MLT-only mode and the server returns MVT, the request fails. There is no reliable way to serve the correct format, making MLT support non-functional in practice. **Describe the solution you'd like** Tile requests should include an HTTP Accept header to explicitly negotiate the tile format (e.g. `application/vnd.mapbox-vector-tile` vs an MLT media type). This allows servers to deterministically return the correct format using standard HTTP content negotiation. If this is not done this way and the client does expet MLT, but we trigger the fallback to return MVT this creates unnesary errors. Not good. **Describe alternatives you've considered** - don't support MLT (not an option) - make mlt vs mvt a global switch in the tileserver (strictly worse, no benefit) - Inferring the format from file extensions or endpoints (brittle at best, requires more changes to add MLT support, bad error messages, no "just works") - ??? **Additional context** This approach was previously discussed but not adopted, which now blocks interoperability between clients and tile servers for MLT. As a tile server maintainer, there is currently no OGC-Compliant correct way to implement MLT support. A related issue is that cache and offline modes are also not format-aware (MVT vs MLT), but that does not change the need for telling the server what is being expected. Rewrite of https://github.com/maplibre/maplibre-native/issues/4235