Add Path::glob() function

[mosra]

[11:10] "hmm, let's stop procrastinating and add the Path::glob(), finally, can't be that hard"
[21:25] WHERE IS MY FLAMETHROWER

When I hit a bug in musl, which is used by Emscripten, I thought "okay fine, one minor wart, easy to workaround". When I hit another bug in an older version of musl, used by older Emscripten, which was impossible to workaround, I said "fine, let's just XFAIL this case". When I subsequently discovered that Windows conflates the error for "directory doesn't exist" and "no matching files found in said directory" I was a bit shaken already, but still managed to invent a workaround that isn't too complex.

But when I saw that the Windows CI is getting stuck on an ASSERT DIALOG BOX THAT I HAVE TO CLICK because I changed PluginManager to use glob() instead of list() + if(!filename.hasSuffix(ext)) continue;, and the error was that it matched a *.modconf instead of a *.mod file (and gotta say, I was lucky to have that test case uncover this GIANT problem), I started getting furious. Then, I discovered this amazing answer, and thought "okay, silly defaults and over-the-top backwards compatibility, I can understand".

Implemented, pushed ...and nothing changed. The reduced repro case matching *.txt files still matched also *.txtlol. Ultimately, what made me snap, was this post from Raymond Chen. YES, AMAZING JOB EXPLAINING HOW YOU "CAN'T" OR "IMPOSSIBLE" OR "OUT OF QUESTION". IT'S BEEN 17 YEARS SINCE THAT POST, WHY DOES IT TAKE SO DAMN LONG TO ADD ONE MORE FLAG TO FIX THIS?! The FindFirstFileEx() has so many possible extension points it makes me sweat, and yet there's still this damn issue where *.xls matches also *.xlsx, *.dat also *.data, THE WHOLE WORLD SUFFERS and you do nothing!!

So, since this is impossible, other options:

• Revert the useless FindFirstFileEx() call because it does not add any value
• "Never use any extension that would have the first three letters same as any other". NO! Sounds like a solution Microsoft would do (except they didn't, with *.docx, *.xlsx, ...). Am I Microsoft? No I'm not!
• Give up on this cursed career, open a brewery, and get gradually pissed at that as well
• Implement the globbing myself. Ugh. On Unix I could use fnmatch(), on Windows there seems to be ... PathMatchSpecEx that I could use as a post-glob filter? "Nice?" I even forgot such word existed.
  • Needs to be done on the wide string, of course, ugh, so I need to first split the basename part and then use that to match the filename. Ugh. Doing the UTF-16 expansion crap twice. Ugh.
  • This whole ordeal still has to be documented and preserved for future generations. To see what we wasted our lives on instead of trying to prevent the environmental apocalypse.
• Due to the excessive workarounds, it no longer makes sense to implement list() using glob() on Windows, revert that
• Yes and of course there are OTHER new bugs in PluginManager, apart from this assert. What's so strange about Bulldog.dll that a *.dll query cannot find it?! Figure out and fix. I hope it's something silly and not the damn glob not returning files it should besides returning files it shouldn't, because then it would be really crappy.
• Also may want to check behavior with symlinked directories and parents, i.e. path/to/symlinked-dir/../*.txt may look somewhere entirely different than path/to/
  • For which it might be good to introduce Path::normalize() and/or Path::realPath()