[IDEA] Split API from application

[mgaffigan]

Is your feature request related to a problem? Please describe.
Writing plugins ties you to a particular release of the application. It is desirable not to require such rigid coupling. It's also annoying to build, since Maven Central does not contain API JARS, and encourages use of non-API surfaces within mirth-server.

Describe the solution you'd like
Split mirth-server into mirth-server and mirth-server-core. (Same for client). Publish mirth-server-core to Maven Central. Version mirth-server and mirth-server-core separately (only changing mirth-server-core when the API shape changes).

[jonbartels]

Does this need to introduce anything to the plugin definition contained in plugin.xml?

Do we need to repurpose the mirthVersion field to express the API versions supported? Do we need to deprecate it and add a wholly new field? I see a few options:

1. mirthVersion represents the API versions it is compatible with, the field name stays the same and this makes OIE compatible with older plugins without changes -> I prefer this option
2. Add a new apiVersion field which clearly expresses the API compatibility. If we do this we need to consider either dropping support for mirthVersion or falling back to it gracefully.

[mgaffigan]

@jonbartels, I've not reviewed the code to speak in specifics, but plugins should be ignorant of the server release version. Plugins should only care about the server API version being acceptable, and exposing the plugin version.

Clean-sheet design for me would be:

• Server release version: 1:1 with the git tag of the codebase used to produce installers, used in the UI for "primary" version
• Server API Version: infrequently and manually updated semver describing a change to the API shape or contract
• Plugin release version: 1:1 with the git tag of the codebase used to produce the plugin artifacts
• Plugin API Version: infrequently and manually updated semver describing a change to the plugin's API shape or contract (omitted for most plugins, since most do not expose API's)
• Plugin dependencies: API version ranges deemed acceptable to allow the plugin to operate. Includes the server, but may also include other plugins (e.g.: http depends on httpauth, datatype-dicom on connector-dicom)

I think most of the version infrastructure in the codebase refers to API versions. Release versions are likely something to add.

An example a few years from now:

• Server version: 2028Q3-51897817
• Server API Version: 4.7.10
• Plugin release version: 2027Q4-e4039605
• Plugin dependencies: { "server": ">4.6.7", "httpauth": ">4.7" }

Other benefit of plugin dependencies specifying names is in handling forks. server-oie vs server-foo.