Rename some internals for clarity

Naming things is famously, uh, less easy than we might hope. This issue tracks two renames I'd like to do at some point:

• Rename the conjecture.data.Example class to Span, as suggested in #4164. The word "example" is pretty badly overloaded in our codebase, and so using a short and distinct word should help - I think it's also more indicative of what this subsystem does. We'll wait for the IR changes to settle down first though.

• Rename the "primary" and "secondary" database keys to indicate that they store minimal and non-minimal failing examples respectively. This has caused confusion before, see e.g. #4155, and should smooth out interoperability with e.g. HypoFuzz. I'm inclined to come up with canonical names + keys for covering examples (including un/shrunk, and location-vs-set-of-locations), and likely provide a helper function to compute said keys.

• ChoiceNode.kwargs to ChoiceNode.constraints, and see if we can find more-specific names for "kwargs" anywhere else

• Consider renaming the label argument in DataStrategy.draw, which has different meaning than the similarly named argument in ConjectureData.draw. Or rename the latter, which is more inconvenient but avoids public API change. (There's also .calc_label(), which relates to the ConjectureData semantics (?))

Start with hypothesis-python/src/hypothesis/internal/conjecture/data.py and inspect the remaining references to the database keys, DataStrategy.draw, ConjectureData.draw, and calc_label(). Done means the unchecked naming decisions are resolved and affected symbols and references use consistent names.