Improve inferrability of isor

[timholy]

This avoids invalidations of in or == for Symbols.

There are several other inferrability issues with this package, unblock being a real champion source, which may essentially be unfixable. Consequently users of this package may have to be prepared for a certain amount of precompile failures.

CC @ChrisRackauckas.

[cstjean]

Hi Tim, thank you for the PR. I merged, but I must admit that I don't get it, I'm out of the loop...

This avoids invalidations of in or == for Symbols.

I understand how your PR makes this function more inferrable, but I don't understand how it affects invalidations. Isn't isor meant to be used in macro code, where inferrability / performance is really not a big concern usually. Will I get it after watching https://www.youtube.com/watch?v=rVBgrWYKLHY ?

[timholy]

Yes, this is directed at latency reduction, but that's probably not the best choice of video. Instead you might read https://julialang.org/blog/2020/08/invalidations/ or watch https://www.youtube.com/watch?v=7VbXbI6OmYo. What this PR does is limit the "damage" for any package that uses MacroTools if one later loads another package that specializes inor ==. The problem here is that the call to in (which ultimately calls ==) is not inferrable, and thus this macro introduces vulnerability to being invalidated.