core chore(maven) Cleanup maven docker processes including postman

Changes

Created a common base configuration for docker-maven-plugin in parent/pom.xml to allow for consistent running across multiple modules e.g. dotcms-core, dotcms-integration and dotcms-postman. This could eventually also be used for IT test services in CLI but is not converted at the moment.
Refactored dotcms-postman as a nodejs module and install and run newman through api methods and a wrapping node script. Note dotCMS/src/curl-test folder containing the tests should be moved into the dotcms-postman folder structure but this should probably be done in a separate commit. Added ability to specify easily which sets of tests to run and replaced some of this functionality that was being handled only in github removing need for custom resolve-postman-collections custom github action.
Created a nodjs-parent module that is the parent of dotcms-postman and core-web to allow for common setup and configuration and binary use between these and any subsequent nodejs modules. nodejs binaries are now downloaded and used from an install folder at the top level of the project. Caching in the github workflow has been modified to reflect this change.
Used a naming convention for the docker-compose-maven plugin to allow for automatic context separation between docker containers started up in each module.
Added consistent maven profile to add remote debugging when starting up from whatever module.
Updated "justfile" with common maven commands for different usecases.
Added linting check step in github actions maven workflow to replace functionality in .github/workflows/frontend.yml
Added formatting and linting ability from Java code in maven and updated pre-commit hook. Made hook be aware of which maven modules are impacted by the staged files in git and added mechanism to update commit to include any changes required. To minimize current impact but to still include mechanism the current code will not format the Java code itself only the pom.xml files are being auto formatted at the moment.
removed dotCMS/src/assembly/descriptor.xml that was being used to create packaged zip file only and not now being used. Equivalent file for docker packaging is dotCMS/src/main/docker/original/docker-descriptor.xml
Fixed timing issue with some postman tests that use {serverURL}}/application/displayip, this resource is cached and cached results are impacting subsequent tests. added ?dotcache=no to prevent this issue.
Added starter version used to build WAR automatically to dotmarketing-config.properties and added logging when embedded starter is used to report this version.
Added ability to create separate property configuration files for different environments e.g. dev,prod that could be used to set default feature flags. Allowed also for a user override file that is not checked in for temporary settings.
Added script in justfile to install and setup default jdk for project using version set in .sdkmanrc
Updated to use consistent user licence path ~/.dotcms/license/license.dat
remove placeholder starter module. This is not needed, starter can be pushed directly with maven command.

checkout "justfile" in root of project for examples of maven commands

Optionally These can be listed and run by brew install just then type "just" in the project directories to list the command options. e.g. just clean-build

This change creates a shared docker configuration for build and run, including the db and search services the defaults are configured in parent/pom.xml. Using this structure makes it easier for other modules like dotcms-core, dotcms-integration, and dotcms-postman to startup services with the same configuration. Individual modules can override elements of the shared configuration to set ports, modify environment variables etc if required. Modules can also decide whether dotcms needs to run as well as its services or just the services e.g. for dotcms-integration we do not startup dotcms in a socker container.

The docker-maven-plugin https://dmp.fabric8.io/ Gives us a lot of flexibility and configuration we can make use of. In particular the default config is set up to automatically use different volumes and container names for each module to prevent clashes. By default also local ports are created dynamically although a module or user can set a port if they choose.

The locally built snapshot docker is used by default but any image can be specified on the command line this along with the ability to provide a unique context name allows multiple versions of dotcms with matching data to be running concurrently and reused. This will make it a lot simpler to compare a released version behavior against local behavior as well as maintaing a context to use for upgrade testing.

By default the current context is stored in named docker volumes, there is a configuration option to map to the filesystem instead although use of this should be discussed if required.

Not all available options have been exposed and there are many more ways we can used this.