Unify string matching code

[johnhaddon]

We're performing various different styles of string matching in Gaffer :

• Python regexes in python registries, with automatic mapping of glob strings to regexes via fnmatch. PlugValueWidget.registerCreator() is one example of this.
• Custom glob style matching in C++. PathFilter is an example of this.
• Regexes in C++ with some odd mapping from glob strings via python bindings. Metadata is an example of this.

We should reimplement all such code to use a single Gaffer class intended for the purpose. The basis for this should be the glob matching implemented in PathFilter - although regexes are more powerful, they're also way more confusing for users, and we haven't had a use case for them yet, despite their availability.

[johnhaddon]

Another argument for glob style matching is that we can avoid having to construct objects as we would for regexes - this is very useful in that we can just have a match function taking const char *, and directly pass in the values we get from StringPlug::getValue(). Otherwise we'd be left having to convert to a regex every single time we accessed a plug, which would be a lot, or having to introduce yet another plug type which stores regexes internally, or some other overly complex thing.

In that case I don't think we really want a string matching object - just a function is sufficient, and allows callers to manage their own storage as appropriate.

[johnhaddon]

I think we're within shooting distance of having this done now. Here's the list of places where we still expose regexes publicly rather than use the syntax from StringAlgo::match() :

• PlugValueWidget.registerCreator() Fixed in Metadata matching improvements #2536
• InfoPathFilter and FileNamePathFilter. These are both deprecated already.
• NodeFinderDialogue. Here we're using fnmatch.translate() so the syntax is practically the same as StringAlgo. This is a trivial change.
• Layouts. Regex taken as a parameter to save(), which we have a todo to remove anyway.
• ShaderUI.appendShaders(). We're using some pretty nasty regexes with this, so it might be tricky.
• ParameterisedHolderUI.appendParameterisedHolders()
• ConnectionGadget.registerConnectionGadget(). We should remove this and use metadata.
• View.registerView(). We should remove this and use metadata.