The oredict storage bus has inconsistent behavior in its filtering compared to GTCEu (and GTCEu's approach makes more sense)

Describe the bug

In the specific scenario where you want to group oredicts with a common prefix (happens a lot in GTCEu oreproc), for example crushedPurified*&(*Aluminium|*Iron|*Gold), you may want to extract the wildcard from the beginning of each suffix in the group like this crushedPurified*&*(Aluminium|Iron|Gold).

This is useful both because it's cleaner, and to save characters (especially important if you want to make the string work for GTCEu filters AND AE2 storage bus, since GTCEu filters have an absurdly low char limit).

To Reproduce

1. Launch an instance with GTCEu and AE2UEL
2. Get some creative cells and add some items with an oredict
3. Make a subnet using the oredict storage bus that should only see part of the ores
4. Use the first kind of formatting, it works
5. Use the second kind of formatting, it doesn't work
6. Test the same string on a GTCEu filter, it works.

Expected behavior

The GTCEu and AE2 filter should operate under the same logic to avoid needing to version the filter strings, and even aside from that, extracting the wildcard from the grouping is more logical.

And to send the strings in a more readable way:
crushedPurified*&(*Aluminium|*Iron|*Gold) should equal
crushedPurified*&*(Aluminium|Iron|Gold)

Additional context

This has been confirmed to be how the parser works by Brachy in the Nomi-CEu Development channel on discord.
"i wrote that parser for ae2 (i made it in gtceu but it got rewritten there)
i just never considered the wildcard to be used on anything else than a word"

Environment

Tested both in GTCEu 2.8.10 Dev environment and Nomi-CEu 1.7.3 instance on SP.

• Minecraft Version: 1.12.2
• AE2 Version: 0.56.5
• Forge Version: x.2860