feat(docker): Introduce reworked docker setup with jar

[MichaelsJP]

This PR introduces a completely overhauled docker setup. Due to the nature of the changes, the old docker setup isn't compatible with this one. No new major incompatibilities are to be expected soon.

By moving away from the old (almost 6-year-old docker structure) we now have the following features available:

• Coherent user permissions
• Clear mount points
• Well documented docker-compose.yml
• Reworked entrypoint with log levels, sensible log messages, debug mode config less configuration etc.
• Reworked dockerfile that is roughly 1/3 in terms of code lines and a lot less complex.
• We now use the jar file in the container. No more .war-File back and forth (finally).
• Multiple ways of configuring ors: config files (yml, deprecated json), container env variables á la ors.*.someting
• Cloud-ready image. Te image can be 100% configured by environment variables (env files) and therefore run in any cloud and Kubernetes infrastructure without much hustle.
• The image itself can be used as a base for custom cloud images as well.

Pull Request Checklist

• 1. I have rebased the latest version of the main branch into my feature branch and all conflicts
  have been resolved.
• 2. I have added information about the change/addition to functionality to the CHANGELOG.md file under the
  [Unreleased] heading.
• 3. I have documented my code using JDocs tags.
• 4. I have removed unnecessary commented out code, imports and System.out.println statements.
• 5. I have written JUnit tests for any new methods/classes and ensured that they pass.
• 6. I have created API tests for any new functionality exposed to the API.
• 7. If changes/additions are made to the ors-config.json file, I have added these to the ors config documentation
  along with a short description of what it is for, and documented this in the Pull Request (below).
• 8. I have built graphs with my code of the Heidelberg.osm.gz file and run the api-tests with all test passing
• 9. I have referenced the Issue Number in the Pull Request (if the changes were from an issue).
• 10. For new features or changes involving building of graphs, I have tested on a larger dataset
  (at least Germany), and the graphs build without problems (i.e. no out-of-memory errors).
• 11. For new features or changes involving the graphbuilding process (i.e. changing encoders, updating the
  importer etc.), I have generated longer distance routes for the affected profiles with different options
  (avoid features, max weight etc.) and compared these with the routes of the same parameters and start/end
  points generated from the current live ORS.
  If there are differences then the reasoning for these MUST be documented in the pull request.
• 12. I have written in the Pull Request information about the changes made including their intended usage
  and why the change was needed.
• 13. For changes touching the API documentation, I have tested that the API playground renders correctly.

Fixes # .

Information about the changes

• Key functionality added:
• Reason for change:

Examples and reasons for differences between live ORS routes, and those generated from this pull request

Required changes to ors config (if applicable)

[MichaelsJP]

@koebi Cannot answer on your comments directly, so I'll answer it here:

I think it makes the code clearer and easier to read, yes.

Fixed. I moved them to its first usage in line 182.

Can these implications be easily mentioned? If so, we might want to do that. If not, that's fine by me.

Not really. It depends on how they read the documentation and what way they're configuring the container user.
Based on that, a simple feedback from the image on the internal is useful. Else, the container will become a small black box.