Fix empty playlists on restore

The PathProbe stores the state (the m_splitPath stack) used by FsDiscoverer::discover(). It assumes that the discoverer calls PathProbe::proceedOnDirectory() in a certain order (it updates its internal state accordingly).

If the "current depth level" or the target path (m_splitPath.top()) is different from the directory name, the directory is rejected.

For example, here are the successive directories considered to discover "/home/user/Music/album/track.mp3" from the entryPoint "/home":

-- depth 0
m_path:            "/home/user/Music/album/track.mp3"
m_splitPath:       ["track.mp3", "album", "Music", "user", "home"]
m_splitPath.top(): "home"
directory:         "/home"
directory name:    "home"
return:            true

-- depth 1
m_path:            "/home/user/Music/album/track.mp3"
m_splitPath:       ["track.mp3", "album", "Music", "user"]
m_splitPath.top(): "user"
directory:         "/home/user"
directory name:    "user"
return:            true

-- depth 2
m_path:            "/home/user/Music/album/track.mp3"
m_splitPath:       ["track.mp3", "album", "Music"]
m_splitPath.top(): "Music"
directory:         "/home/user/Videos"
directory name:    "Videos"
return:            false

-- depth 2
m_path:            "/home/user/Music/album/track.mp3"
m_splitPath:       ["track.mp3", "album", "Music"]
m_splitPath.top(): "Music"
directory:         "/home/user/Music"
directory name:    "Music"
return:            true

...

The problem is that it can only work if the first directory (the entry point) does not contain more than 1 token. For example,

-- depth 0
m_path:            "/sdcard/emulated/0/Music/track.mp3"
m_splitPath:       ["track.mp3", "Music", "0", "emulated", "sdcard"]
m_splitPath.top(): "sdcard"
directory:         "/sdcard/emulated/0"
directory name:    "0"
return:            false

Since the initial directory is "/sdcard/emulated/0", the directory name ("0") does not match the first token of the target path ("sdcard"): the internal state of PathProbe is inconsistent with the sequence of calls it expects from the discoverer.

This commit quick-fixes the problem by handling the entry point separately to "consume" all the initial path tokens, so that the internal state of PathProbe is synchronized with the calls it receives from the discoverer.

---

This fix is not very elegant (it adds another assumption on the order of the calls by the discoverer), I would like to discuss with @chouquette for a proper solution. :)