Ensembles 3.0.15

• alwaysMergeFileContent no longer breaks apps that passed a full cloud path, and files from the old location are not stranded. 3.0.14 moved the directories registered with alwaysMergeFileContent(inLocalDirectory:withCloudDirectory:) from the root of the cloud container into the ensemble's files directory (/<ensemble>/files/), where Ensembles 2, mergeFileContent and deleteFiles put them. That was right as a destination but wrong as a patch: an app that had passed the full path, because 3.0.0 to 3.0.13 resolved this one call from the root, had its path doubled and every sync failed with "file does not exist"; an app that had passed a short name saw its files move and its devices stop sharing them until all had updated. Now a path that already starts with <ensemble>/files/ is used as it is, for all three calls, so such an app needs no change. And on every sync, files still at the old root location that are missing locally are downloaded, with nothing uploaded there, so a device on 3.0.13 keeps syncing files with a device on 3.0.15 in that direction, and nothing a fleet already has is lost. deleteFiles removes a file's copy at the old location as well, so a deleted file does not come back from there (on 3.0.13 it did, since that call already used the files directory). A registered name equal to the ensemble identifier is never read as an old location. If your app calls alwaysMergeFileContent, skip 3.0.14.
• MemoryCloudFileSystem lists a directory like the other backends. It returned every descendant as a file, and matched a sibling whose name merely began with the requested path. It now returns the direct children only, with directories as CloudDirectory.