Test selections

This is a feature we've been thinking/talking about for quite some time, see an earlier draft pitch document here: https://nextjournal.com/lambdaisland/pitch-test-selections

Test selections are a way of encoding subsets of tests, across all tests/suites that are defined, e.g. by metadata matching, by name, by type. One can then choose to run all tests within such a selection (similar to how you choose to run tests within a suite), or to run all tests that don't match a certain selection. This means that selections can be negated, which fixes the common anti-pattern of defining suites that either match or don't match a certain criteria, in order to have complimentary suites (e.g. fast vs slow tests).

This would also provide a solution to #31 by having the concept of a "default" selection, that defaults to all test suites, but can be redefined.

Start by reading the linked pitch document and issue #31 to understand the proposed test-selection and default-selection behavior. Then inspect the existing test suite and selection-related entry points, if identified during that review. Done means an agreed implementation supports metadata, name, and type matching, negation, and a configurable default selection.