Create versionned directories of the helpers

[Salamandar]

The problem

Having a single helpers directory completely freezes its API, we don't want to change it by fear of breaking old or unmaintained apps.
But sometimes we see bugs, deprecated functions, want to change the overall API, want to introduce new behaviours.

Solution

This MR introduces a new variable, YNH_APP_HELPERS_VERSION.
It's supposed to be synchronous with the YNH_APP_PACKAGING_FORMAT, usually. But we might want to have 2.x versions, as a preparation for manifestv3 for example.

This variable can be passed as an env var, or as the first arg of the script (source /usr/share/yunohost/helpers 2.1). It defaults to YNH_APP_PACKAGING_FORMAT or to 1.

Directories are named helpers.v${VERSION}.d.
A symlink helpers.d -> helpers.v1.d keeps the "legacy" directory.
The version 1 is the current one, so old packages won't break.
The version 2 is a symlink to v1, so current manifestv2 packages will be fine too.

PR Status

Completely untested.

How to test

...

[kay0u]

I like the idea, but I'm not sure that the package version must follow the helper version.
To me it's completely uncorrelated, and we could have a turbo package V5 with helper v2 because it doesn't evolve as fast as the package needs etc.

We could use a key in the manifest, and if it's not declared, use helperV1.

[Salamandar]

I'm not sure that the package version must follow the helper version. To me it's completely uncorrelated, and we could have a turbo package V5 with helper v2 because it doesn't evolve as fast as the package needs etc.

If i understand your idea correctly, you would just like to decorrelate versionning of the 2 ? That i'm fine with. Correlating the two numbers was just a simplification. We just need to be clear about the "compat matrix". (for now packagingv1 is helpers v1, packagingv2 is helpers v1 and v2).

We could use a key in the manifest, and if it's not declared, use helperV1.
Yes that's what I did :)