Testing: profiles for padding, padding color, post-creation config

[DJMcNab]

Adds support for configuring how padding in renders done by Masonry Testing is done at runtime.
Also adds support for configuring the padding colour.

Additionally, this adds targeted methods for the archetypes of screenshots identified in #1457

This is now applied to button (and text_input, as if it were the default)

[PoignardAzur]

I don't remember if we talked about this, so I'll just leave a review now: I'm not a fan of the new padding color in the changed screenshots. In fact, I'd maybe consider it a regression.

I think having the padding color be a different color than the background (e.g. what you see behind the rounded corners) is visually confusing and kind of defeats the point of adding padding in the first place.

I'm open to changing my mind if there's a strong rationale though.

[DJMcNab]

I'm happy to remove the colour. I still think that having padding in the vast majority of screenshot tests is valuable:

• It makes intentionally "overdrawn" content visible (e.g. shadows, focus indicators)
• It makes screenshots easier to parse in that the widgets are shown more "in-situ"

I do feel that having some indication of what the padding region is does have value, in that it allows "unintentional" overdraw to be caught. Overdraw can at least be manually detected with the debug paint?

---

As a procedural note, we seem to be talking past each other. Once we remove the default padding colour from this PR (or in the follow-up to actually enable the default padding), we're back in the state from before #1457 (review), in that the newly added default padding wouldn't be discoverable.

However, there is another assumption which this PR is making, which might not be true, which is that the "screenshot of individual widgets" case is the common-case. It certainly is in this repo, but it really isn't for users of Masonry. Because of this, it feels like there might be some solution which satisfies all of our needs.
I still strongly feel that making every test opt-in to padding is a really poor solution, for the reasons I've already outlined (in the happy case it's just boilerplate, and for tests which accidentally don't opt-in, it makes for confusing inconsistencies).
However, if it is the case that for a given TestHarness, it's serving one of the identified roles in about equal measure, suddenly a more explicit API becomes more appealing. However, I feel that in that case, setting which class of test harness you explicitly are needs to be enforced, i.e. it's not like you say TestHarness::new makes a test harness with no padding, which isn't actually what we recommend for anyone to use.

I'm not sure however how to make such an explicit API ergonomic, whilst still being explicit enough that padding is being added to meet your discover-ability targets (e.g. saying TestPadding::SingleWidget adds a lot of characters, and will push rustfmt into a very verbose formatting).