WIP - multiple versions in work packages

[brunopagno]

Epic - https://community.openproject.org/projects/stream-jira-exit/work_packages/71752/activity

The idea is that work packages should two standard fields for versions, each should be able to reference multiple versions:

• the versions which entail the work that is the result of what is described in the work package. Similar to the current version but simply plural. They are basically the target versions.
• And for classical issue tracking/bugs/errors/fails another field Observed in versions to track where an issue was spotted.

But to get there, there are a few open questions to which I am not sure how to deal with, yet.

Assumptions

• A version is a model defined in version.rb, so no new "version" models will be defined.
• Relations between multiple versions and work packages will exist in a single many2many relationship with a "kind" field defining which type of version that is. Meaning there will be a work_package_associated_versions table with a field kind which can contain values "target/observed_in".

WorkPackageAssociatedVersion
- work_package_id
- version_id
- kind ["target"/"observed_in"/"newversiontypefromthefuture"]

• We will replace the usage of work_package.version everywhere for work_package.release_version.last (or something similar), and create a Setting configuration where admins can enable/disable multiple versions per work package.
  • This comes with it's own issues, because disabling such setting means destroying/hiding data.
• We will do a one time migration from versions table to release_versions table, when the feature is released, and from there on, we will rely on associated_versions for everything, effectively deprecating the work_package#version field. [WL: I Maybe I don't understand it properly. but why would the versions table need to be migrated? They are still the same thing: versions. They are not necessarily target versions or release versions]

A rough plan (Work in Progress)

This PR:

• FEATURE: Create and make new versions fields available on work packages
  • Behing a feature flag

Future work:

• FEATURE: Define a Setting for using single or multiple versions
• FEATURE: Handle seeding and defaults for form configuration for work package types
• FEATURE: Adjust the behaviour of the roadmap module to work with new version fields
• FEATURE: Adjust the behaviour of filters/groupby/sorting for new version fields

More context at https://community.openproject.org/documents/206

[brunopagno]

Closing in favour of #22473
This one was becoming too messy