Rework Import/Export versioning mechanism: define the forward and backward compatibility

In our current implementation of Import/Export, we could not make the Import from the previous version of the Export.
https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/import_export/version_checker.rb#L30

From the discussion in !17949 (closed), it seems that we try to avoid/delay updating the version of import/export as much as possible because we don't want to break compatibility.

To continue reworking import/export, we will need to bump the version and still support (import) older exports.
The current implementation will block us.

There is a detailed proposal from Kamil how it could be changed: !17949 (comment 229383502)

Example 1:
Relations rename. We should be comfortable supporting both old and new relation schemes for a number of recent versions. We should avoid duplicating both relations in the export (currently, it hits performance/memory).

Example 2:
Having new relations added to Export/Import, it should still be possible to import older versions of the exports.

For these cases, having a separate version of the importer and the exporter could give us more flexibility.
For example, Importer v2.3 may not support exports made with Exporter v3.0, but is aware of exports made with Exporter v2.1 and Exporter v2.2 and supports them. At the same time, compatibility with exports created by Exporter v.1.N could be deprecated.

Concerns:

• To migrate to the new mechanism, we will need to have some transitional version of the logic, which is compatible with the current implementation.
• (please comment on the issue)