Overload generation mode: support enumerating the rules

[oxinabox]

Right now, we don't provide any way to list out all rules.
A bunch of packages that use DiffRules assume that that is possible.
And then they take that list and use metaprogramming to overload some methods.

I am thinking we should maybe provide a legacy support function that does this.
That uses methods(frule) and then filters it for things that promise not to return nothing.

And we call it something that makes it clear that it is not advised to use this.
Since it prevents extensibility in other packages)
(but we can give advise to e.g. ensure the latest set of rules can be loaded via calling update_rules or something.)

[oxinabox]

Probably we want to actually return a collection of splitdef style Dict rather than a Method object.
As that is easier to Metaprogram around.
We would not have a body but would have the other fields per:
https://github.com/invenia/ExprTools.jl/blob/9a0a61f7407b9ad9867f337d27fb27fd867c0506/src/function.jl#L6-L13

[oxinabox]

Key tool is being made in
invenia/ExprTools.jl#1

[oxinabox]

details on issue with this;

Consider:
if some AD package call it AD.jl, did at top level:

using ChainRules
for ruledef in list_rrules()
    @eval _pullback(, ruledef.args...) = rrule(ruledef.args...)
end

and we had packages
Foo.jl defining the rrule for foo
and Bar.jl defining the rrule for bar

and the user did:

using Foo
using AD
using Bar

then AD.jl would not see the rrule for bar`

---

There is a callback/hook in base that happens each time a new package is loaded,
(see its use in Revise.jl
so maybe we provide something based on that, which lets AD packages “Subscibe” to the creation of new rules, and they provide a function (taking a ruledef as input and calling eval on a expression)
and we track which ones we have given them and give them any new ones to reevaluate using their function.
And we can make the hook fast(ish) by just checking if the number of methods of rrule or ffrule has changed.

[oxinabox]

Wants invenia/ExprTools.jl#2

[oxinabox]

Might want to retitle this as I think we may want to make it a first class way of using ChainRules. Because Cassette type-inference issues do not seem to be going away anytime soon

[oxinabox]

I think i have been over engineering this.

I think we can just solve this via:

• a hook for frule and rrule that AD Packages provide a function for which takes an AST and tranforms then call eval on it, if they want
• a @frule and @rrule macro (cf Delaration helpers #44) which just scopes up the whole function that is put in from of it, then spits it backout + a call to trigger_hooks to which it passes the AST

Only thing missing is that I think it would be good if we had the Method object to pass to the hooks as well. Or at least the Method.sigt thing which is a tuple type of all the arguments used for dispatch, so that the hook writes can see what they are hooking to to.
But maybe that came come later.