Add Regex Engine to FEX for config option loading

[badumbatish]

Hi there, i'm opening the PR to add a small regex engine to the Fex codebase. The motivation is to help dynamic modify some config option based on the name of the config file. Please see the following screenshot for more context.
.

The regex engine is an NFA based one, implemented from the dragon book 2nd ed.

Implementation is in FEXCore/Source/Utils/Regex.cpp.
Test case is unittests/APITests/Regex.cpp.

I took the liberty to refactor and reuse a bit of the code in parsing the json. The traversing of a json list of pair of strings is now a helper function called ListApplier that accepts a json_t.

The default behavior is that the config loader goes through each regex and see if it matches the config name, if it does, it applies the config option specified and then stops checking anymore regex (this can change based on the need and reviews of the PR).

I'm not sure where should i add the test case for the new config loader. I tested locally via /home/ubuntu/.fex-emu/Config.json and it works, would love some suggestions

{
  "Config":
    {"RootFS":"Ubuntu_22_04"},
  "ThunksDB":{},
  "RegexConfig" : {
    ".*" : {
      "RootFS":"Ubuntu_24_04",
    }
  }
}

[bylaws]

I'm unsure on a full regex engine, I think a very naive glob impl might be enough. albeit this is very neat

[Sonicadvance1]

Other than the concern about the licensing of the regex engine used, I'm fine with this type of change.

[neobrain]

I'm unsure on a full regex engine, I think a very naive glob impl might be enough. albeit this is very neat

I'd like to echo this - adding a full-blown regex engine without documentation and bare-bones unit tests is overkill for the concrete feature this PR intends to add. (Though I do appreciate that there are tests :) )

Could you focus the implementation on pure wildcards (* instead of .*) instead, without unions and the other features that we don't need for config matching? That should allow for throwing away most of the complexity here, notably the use of NFAs.

This doesn't necessarily imply a rewrite (up to you). Deleting the relevant code and taking a quick pass over what's left would yield an equally simpler result.

[badumbatish]

I've gone ahead and removed some features like unions, escapables, question, plus. Please let me know if this is sufficient for the PR

[neobrain]

Thanks, this is much easier to read :)

Adding a few more comments, no big changes though!

[neobrain]

What do you need feedback on?

[badumbatish]

I mainly would want to know if the current approach of applying the config is good or not

[neobrain]

Oh, you'll also want to run clang-format-19 on any newly added code. (I think most of us have our IDEs set up to auto-format on save.)

[badumbatish]

Oh, you'll also want to run clang-format-19 on any newly added code. (I think most of us have our IDEs set up to auto-format on save.)

gotacha i'll install it

[badumbatish]

Apologies for the delay i was on vacation. I've addressed the comments

[neobrain]

Apologies for the delay i was on vacation. I've addressed the comments

No worries, though you arrived just in time for my vacation and sadly no one else was around to take over the review.

Not exactly sure what's going on with the CI build failures - could you rebase the PR onto latest main to see if it still happens then?

[Sonicadvance1]

The CI build failures come from pulling in headers from a FEXCore library but the test isn't linking to that library.