Allow style properties to be accessed directly on the widget

[mhsmith]

Closes #3011.

See design discussion starting at #3011 (comment).

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[mhsmith]

Although this argument is currently only used for styles, I called it kwargs rather than anything style-specific, because at some point I’d like to have a larger cleanup of constructor arguments in which non-style properties could be included. I'll write this up in a separate issue (#3134).

[mhsmith]

I put the style properties into a separate base class to avoid them cluttering the documentation.

[freakboy3742]

This all looks fairly straightforward. I've flagged a couple of testing issues, and pushed some tests to cover those cases.

The only other concern I have is that this binds Toga's widgets to Pack as a style implementation. However, for the sake of practicality, I can live with this. There's no really viable alternative to Pack on the immediate horizon, and with the recent Pack name changes to align with CSS, all the descriptors that have been added here will be valid for Colosseum/CSS users anyway. If other style engines become a realistic possibility, we can always revisit how the descriptors are bound, and the clear separation of mixin from widget means introducing a new approach should be relatively clean.

I'm happy to approve as is; the only other thought I've had is whether it might be worth to not install descriptors for deprecated style properties. There isn't currently any formal annotation of deprecation status that we could use for this purpose... but it shouldn't be too hard to add that sort of annotation. I'll leave it up to you if you think that's worthwhile.

[mhsmith]

It looks like the only deprecated property that has a descriptor is alignment, as the padding to margin rename was handled via __getattr__ and __setattr__ methods in the Pack class. Accessing it via Widget will give the same deprecation warning as accessing it via Pack, so I don't think it's worth any extra effort to exclude it completely.