Perform health checks for each component of a strategy

[Zac-HD]

As part of our eternal quest to stop people (accidentally) misusing Hypothesis, we have a number of health checks to warn about strategies that will have poor shrinking behavior or are impossible to draw from.

• binary(9000) fails with large_base_example, because the minimal example is too large (Add new health check for large base examples #996). binary(9000) | none() has the same error, for the same reason.
• none() | binary(9000) should (Failure of duplication detection during generation #995) fail with an error related to duplicated examples.
• text() | binary(9000) should (this issue!) fail, because there is a branch or component of the strategy which cannot ever be drawn from. See these comments:

A possibly more fruitful approach is that we do a bunch of random generation that basically inserts this approach [trying the minimal example] on the first draw call to every strategy it sees. We'd need some decently reliable way of distinguishing strategies (I've been vaguely meaning to do something about this with a hashing scheme but haven't worked through the details). At any rate, I think this is definitely too big a change for now.

This issue is meant to keep track of that ambition.

[Zac-HD]

#1112 is a real-life example of too much filtering in a sub-strategy (field for a Django model).

[Zac-HD]

A closely related problem is that the error messages for failed healthchecks do not show the strategy which failed the check!

hypothesis.errors.FailedHealthCheck: It looks like your strategy is filtering out a lot of data.

Adding the repr of the relevant strategy would probably be helpful right now, but even more so when we can run this check on smaller parts and discover the minimal unhealthy components.

[Zac-HD]

Overlaps substantially with #434, which proposes yet another solution.

[Zac-HD]

#1153 would also be easier to solve with more granular reporting of health check failures.

[Zac-HD]

Post-#2030, I'm closing this as the remaining parts are better described by #434.