Make FluidFilesPath class more robust

[weefuzzy]

Non-urgent quality of life improvement for devs:

It's a relatively trivial change, but smacks of Being Clever, so I'd be grateful if @tedmoore could look it over and see if there's something I've not considered.

FluidFilesPath works ok at the moment, but relies on a relative path formulation to guess where the resources directory is.

I've come across an edge case that breaks this whilst putting together an improved development experience that creates a mimic of the final installed package layout, but with symlinks for everything*. At this point, using a relative path in sclang breaks, because it just sees through the symlinks and looks in the wrong place for the resources folder.

What this does instead is – once – scans through all the packages that Main.packages knows about, and looks for path matches likely to be unique to flucoma (Resources/AudioFiles/Tremblay*), in order to reliably locate the actual package directory on disk (whether populated by symlinks or not).

* Which is really cool (you can edit classes and help files in place, and everything just works! Except this) – it's all part of a cmake overhaul

[tedmoore]

I haven't tested it, but knowing you, I know you're not shooting from the hip. This looks super. I've tried to think of edge cases that this might run into but I can't think of any. ❤️