getall: cleaner, support Recursive

[aplavin]

Here, I try out a different getall implementation based on the trick from FluxML/Functors.jl#61.
It:

• doesn't require code generation (one internal @generated function remains, but maybe it can be removed?),
• support Recursive, even easier than ComposedFunction!
  Can potentially close the getall part of get/set all values referred by an optic #63, Leaves optic #14, get/set queries #23.

The getall limit for ComposedFunction inference seems to become lower than before, though. It affects one test that tested the maximal depth of 10.
Well, the getall(ComposedFunction) implementation may stay as before with @eval, only adding Recursive from this PR...

@jw3126 @rafaqz @cscherrer

[bgroenks96]

Hey @aplavin what happened with this PR? Is there something blocking it?

[aplavin]

For reducing code generation (@eval) in getall: there's no pressing need to do that, and apparently the compiler still cannot optimize it in all cases:

The getall limit for ComposedFunction inference seems to become lower than before, though. It affects one test that tested the maximal depth of 10.

---

For adding Recursive support: it can be done I guess, but is it needed? Anyone using Recursive at all?
IME, it's quite hard to use in practice; I can recommend RecursiveOfType from AccessorsExtra.jl instead.