Move away from hardcoded SOP classes and transfer syntaxes

[Enet4]

I have been thinking and I have come to realize that it was a poor decision to keep a hardcoded record of SOP classes and transfer syntaxes. The problems with this approach:

• Every once in a while, new storage SOP classes are standardized that would be perfectly fine for the archive to receive and store+index like other DICOM objects. Updating this requires an error-prone (#215) modification to the core project sources.
• Dicoogle has been designed with extensibility in mind ever since the plugin-based architecture. However, this hardcoding makes it nearly impossible (at least utterly inconvenient) for developers to experiment with new transfer syntaxes.

I suspect that this might be a breaking change due to some internal details, but this needs a better assessment.

Acceptance criteria:

• The list of supported SOP classes and the list of supported transfer syntaxes should both be extensible independently, via configuration.
  • Let's try using new categories in confs/server.xml for this.
  • Each custom SOP class or transfer syntax should specify a UID and alias. Once done, that entry is added alongside the hardcoded default list (so these records cannot be removed)
  • This configuration can be empty or unspecified.
  • This list is not sufficient for the DICOM storage server to accept those SOP classes and transfer syntaxes. This must be configured as usual.
• Server settings should be validated for unspecified UIDs, but it must let users specify well configured UIDs and have that applied in the DICOM storage server.
• The user interface should acknowledge the extended list of SOP classes and show options for the extended list of transfer syntaxes.