Improve how taxonomy fields are added to document types using the document type editor

Currently, the UX for adding a single taxonomy field to a document type is somewhat strange, using the Classifiable mixin, rather than treating this as a normal document field. It is apparently impossible to add more than one taxonomy field via the UI. Investigate the implementation and propose options to make this conform more naturally with the way other field types behave in our system.

Also include in your review the "canonical" extension to taxonomy usage. Does this feature constrain the technical alternatives? Should we continue to support it?

Solution design

• Refactor the TaxonomyPickerPlugin to use/follow a similar (and more simplified) approach used for the DynamicDropDown from the selections plugins project
  • it becomes available as a 'regular' field plugin in the document type editor, linked to and configured with a proper hipposysedit:nodetype/hipposysedit:field, which is (re)nameable as desired when setting it up
  • the taxonony 'source' for the field can be configured (just like for the DynamicDropDown) with the linked taxonomy (document)
  • besides just text entry, we may also be able to provide a proper 'taxonomy document picker' dropdown instead without too much extra effort, which then completely removes the need for providing this feature through Essentials (separate from the creation of new taxonomy documents)
  • it no longer uses/depends/requires the Classifiable Mixin (document type editor) functionality
    • that mixin (hippotaxonomy:classifiable) really isn't used in practice, except for one (wrong/insufficient) scenario: searching for existing documents referencing a specific taxonomy before removing it (remove button in taxonomy editor)
      • that logic isn't sufficient  (and can be regarded 'buggy') because:
        • there could be multiple taxonomies using the same 'key' (or category): the classifiable mixin on a document itself cannot tell which taxonomy is used
        • there could be secondary (or more) taxonomy 'keys' properties in use on a document which are 'unknown' (and not linked to the mixin)
      • a proper implement for that logic needs:
        • finding the document type(s) having a field configured as a taxonomy field (e.g. through the TaxonomyPickerPlugin) and is linked to this specific taxonomy (in the TaxonomyEditor)
        • search for all documents of these type(s), with that/those (could be multiple) field(s) (their underlying property name) and that specific taxonomy key configured in its values
        • none of the above needs the mixin
• The current TaxonomyPickerPlugin delegates all its keys get/set handling to a ClassificationDAO implementation, registered as a service in the CMS: we don't need it!
  • This also is used and needed to be extended/configured with an additional ClassificationDAO 'service' when adding an additional taxonomy keys field in one document type
  • The ClassificationDAO solution is awkward, requires additional (console level) configuration, is brittle (you cannot reuse the same 'service' for the same taxonomy in another document type: you need to create yet another one for that)
  • We don't need this indirection: all the logic (which is pretty trivial) can easily be merged/moved into the TaxonomyPickerPlugin itself

• The Canonised extension (hippotaxonomy:canonised) of the Classifiable mixin may be considered (or made) redundant:
  • it provides and uses an additional hippotaxonomy:canonkey property, which is used to mark which of the taxonomy keys configured is to be treated as 'canonical'
  • this is supported (but totally undocumented) when the TaxonomyPickerPlugin is configured for/with a Canonised mixin, and then used to 'maintain' the extra (hidden) canonkey property as well
  • instead we can implement/provide (almost) the same behavior and functionality with just the single multi-valued taxonomy keys property itself:
    • those values are ordered by definition
    • we can 'promote' the first value to be regarded as 'canonical' (which already is the existing behavior when the current 'canonized' value is deleted)
    • the UI (TaxonomyPickerPlugin) doesn't need to be modified at all, just the implementation logic:
      • when another (not the first) taxonomy key is made 'canonical' (which is link action) we can simply reorder the keys values by shifting that selected value to the top
      • deleting the current canonical key actually becomes easier (a noop)
    • we no longer need the additional canonkey property
    • the only, really minimal, change in behavior and functionality is that the ordering of the taxonomy key values (then, for Canonised use-cases) no longer is independent with respect to the first entry
  • given the above changes, we also no longer need the Canonised mixin, we can just use the normal Taxonomy field with one extra/optional boolean flag (default false) to indicate the usage of the 'canonised' purpose.