Use Sailfish.Pickers.FolderPickerPage to configure music directories

[smokku]

Replaces custom AddFolder dialog with Sailfish FolderPickerPage.

Should help resolve #26 confusion.

[Olf0]

@smokku, thank you very much for this and your other contribution (MR #34).

^{Sorry for the long delay, I was knocked-out by influenza etc. from early December until mid January and now I am trying to catch up with my backlog at work, private stuff and last, but not least SFOS-related stuff.}

Note that FlowPlayer's code-base currently supports all releases since 1.1.9 (maybe even 1.1.7), that the GitHub CI workflow compiles for some releases starting with 2.2.0 and that SailfishOS Chum supports all releases since 3.1.0.
Mind that users of a Jolla 1 are stuck at SFOS 3.4.0 and users of devices with community ports of SFOS at various releases.

Thus a mechanism for different code paths to target different SFOS releases has to be employed, before merging this PR.

• The theoretically more elegant solution is achieving this by ifdefs / ifndefs (or something similar) in the code and / or spec file. This way a single code base covers all SFOS releases. But this scheme can clutter the source code in the long run, if there are many deviations (Jolla tends to often introduce breaking changes). Plus I never implemented anything such or maintained such an implementation.
• A simpler approach is to handle changes breaking backward compatibility by using different source code branches. Such a scheme is detailed in Storeman-Wiki:Git-commit-workflow. This is a scheme I am using for a couple of projects.
  For an example, see the coding differences between the old (< SFOS 4.2.0: Sailfish.TransferEngine) and new (≥ SFOS 4.2.0: Sailfish.Share) sharing mechanism in Storeman: Storeman@sfos3.3...sfos4.2

I consider implementing the second scheme some day, unless someone (you?) poses a merge request with some (e.g. the first) approach meanwhile. In the latter case, I just have to review, which should be done quicker.

Either way it is necessary to know the exact SailfishOS release, which introduced a change; because this is the minimal release for which switching the code ("… base", when using the second, simpler approach) is feasible. This documentation can be helpful for researching these. Please reference the source(s) of this information by web-links, when providing the result of this research here.
AFAIU, the current, old code base still works with the current SailfishOS release (4.5.0), hence a SFOS release for which switching the code ("… base") is required does not yet exist, correct?

[dcaliste]

I rebased on latest devel and try to detect if Pickers are available on the current run. Fallback to the old code if the Pickers are not found. Otherwise, use the new code proposed by @smokku.

@Olf0, if @smokku agrees, you may want to squash the 2 commits for clarity of the history.

[smokku]

Fine with me. 👍

[Olf0]

you may want to squash the 2 commits for clarity of the history.

BTW, I squash-merge feature-branches by default, unless there is a reason not to, e.g. separate commits provide some kind of clarity to a reader later on.

Here, I would sure squash-merge by all technical aspects, but that obfuscates that there were two different contributors (i.e. a social aspect). Well, I can name you in the commit message, if I do not forget to.

Will review and (likely) merge tonight.

[Olf0]

LGTM

[dcaliste]

Thanks @Olf0 , no problem to loose the ownership of changes on the few lines I modified. That's fair that the commit stay with smokku authorship. He had the idea and proposed the core of the changes.