Use a macro to implement context methods

[cmyr]

This attempts to solve the issue of duplicate code and out of
date documentation for methods shared between multiple contexts.

The approach taken here is to use a simple macro to implement
those methods.

The macro was actually a real pain to write, and kind of gross API
wise; in particular you need to pass in all of the lifetimes twice.
I've given up trying to improve it, and given that this is private API
it doesn't matter too much, but it does offend my sensibilites
somewhat.

There are a few bits of future work; window & window_id should
be shared between all contexts, but that requires a change to
PaintCtx; another change would let us reuse is_focused.

In any case, I think this is a step in a good direction.

This is based off of #970, which should go in first.

[xStrom]

I really dislike macros for large amount of code because cargo fmt doesn't work on it. There's misformatted stuff in this PR already, but more crucially this will lead over time to either the formatting being a mess or PR review time spent on doing human powered cargo fmt.

I propose we try to solve this using traits instead. One possible way can be seen in #974.

[cmyr]

/bloat

[xStrom]

If we do continue with a macro for docs purposes, then I wonder if we can somehow have the function definitions/comments outside of the macro, and then a macro that takes a reference to the code. That way cargo fmt could still work.

[cmyr]

The alternative to a macro that would let us do something like that would be to use build.rs and do codegen. This feels a bit worse in some ways (less discoverable, maybe harder to read the code?) but would at least ensure formatting.

[xStrom]

I read through a bunch of rustfmt issues and apparently it does do formatting in some specific macro cases. It was unclear which though. However there might be a chance to someshow either restructure the macro or wrap individual functions in another macro to enable formatting.

[cmyr]

I played around with this without luck, if you've read any issues about this that have reasonable explanations I'd be all ears?

[xStrom]

Okay so I did some more extensive googling and it seems that the macro usage cases that get formatted are expressions. [1] [2]

I tested a simple macro that just takes an expression and fed it a function and cargo fmt indeed formats the function and its body.

[xStrom]

I couldn't get it to work in relation to this PR, although I'm not experienced with macros and may be missing something.

More generally I guess we can minimize the amount of formatting trouble by keeping the macro'd methods mostly lightweight shims and if we need actual work then do that in another method somewhere, e.g. on WidgetState etc.

[cmyr]

@xStrom assuming that we can land #996, this now works with rustfmt (since we don't need to have any explicit lifetimes in our impls).

I'm pretty satisfied with this, since it also let me really clean up the macro itself, which is now much less gross.

[cmyr]

this should now be gtg? It also has one cool property I hadn't really considered: you now need to think really consciously about what set of contexts a method should belong to, which means it will be much rarer for something to just randomly not be available on, say, LifeCycleCtx.

[luleyleo]

I think this is a nice consistency and maintenance improvement, now that fmt works.
One typo but looks good overall.

[xStrom]

Looks good!