Rather than it being about widgets where `can_focus` is `True`, have it be
about widgets that are currently able to receive focus. Before this change
widgets with a positive `can_focus` but which were disabled would still end
up in the chain.
We want to maintain `can_focus` as "this is a thing that can, at some point,
receive focus, assuming it isn't disabled". So `can_focus` is now very much
about the ability to receive focus at all.
The new `focusable` property becomes about "can this widget receive focus
right now?".
[This is a rewording of a previous commit -- I get the wrong thing]
There's still a bit to do here, but this migrates the main work up to the
`Widget`. At this point `Button` is pretty much built expressed as a
function of what `Widget` provides in terms of things being disabled.
Focus can still move into disabled controls (or in this case right now, into
a disabled `Button`). The next step is to add something that works alongside
`can_focus` to say if a control is currently capable of receiving focus (in
other words, it's `not disabled and can_focus`).
I was going too early with setting this; it needs to happen after pretty
much everything else is set up *and* after the super's __init__ has been
called.
It's done as an internal, but can be called from child classes of course.
This is intended to be a single central method of asking the app to update
styles while also not caring if there is no active app available just yet.
Note that this doesn't touch the application of stylesheets yet, in terms of
things like specificity; this just makes sure that the classes exist and can
be seen.
This seems to be a hangover from the early days of the development of
`Input`, and the styles do nothing as there's nothing else in the `Input`
code that makes use of the class that's involved.
Removed in anticipation of #1748 taking care of this.
