gf: improve ordering of operations based on performance estimates

[vtjnash]

In the last commit (#36166), I didn't expect NamedTuple to hammer our
performance, but was starting to notice performance problems with trying
to call constructors. It's somewhat violating our best-practices in two
common cases (both the constructor and structdiff functions are
dispatching on non-leaf types instead of values). That was putting a lot
of strain on the cache, and so it forms a good test case. Keeping those
cases out of the cache, and searching the cache in a more suitable order
(significant mainly for constructors because there are always so many of
them), offsets that--and seems to probably make us faster overall as a
bonus because of that effect!

Here's what I was measuring that was highlighting this issue:

julia> @btime methods(==, (Int64, Int64)) 
   1.248 μs (18 allocations: 784 bytes) # before PR
  32.553 μs (18 allocations: 784 bytes) # master now
   1.310 μs (18 allocations: 784 bytes) # this PR

[JeffBezanson]

Yeah, I see structdiff show up a lot in various profiles. I've thought about other ways to write it. One possibility is a getfields builtin. We could also pass in Val{names} instead of NamedTuple{names} if you think that would help. Any other ideas?

[vtjnash]

Possibly: that'd help avoid the awkward <:Tuple constraint, though perhaps at the risk of introducing even more DataType objects. Regardless, this PR is an improvement, since I don't want some other user types like this (there's already a couple) to be slowing down other constructor calls.