Introduce `target` annotation attribute for `@Execution`

[marcphilipp]

Similar to the target=SELF|CHILDREN attribute added to @ResourceLock in #3102, the @Execution annotation should also receive such an attribute to support the following use cases.

Class level

In this case, using target=CHILDREN would have the same effect as declaring @Execution on every @Test method of the test class.

@Execution(value = CONCURRENT, target = CHILDREN)
class SomeTests {
    @Test
    void test1() {}
    @Test
    void test2() {}
}

would be equivalent to

class SomeTests {
    @Test
    @Execution(CONCURRENT)
    void test1() {}
    @Test
    @Execution(CONCURRENT)
    void test2() {}
}

Annotations on test methods should override annotations on the class level. Therefore, test2 from the following example should use SAME_THREAD while test1 should use CONCURRENT.

@Execution(value = CONCURRENT, target = CHILDREN)
class SomeTests {
    @Test
    void test1() {}
    @Test
    @Execution(SAME_THREAD)
    void test2() {}
}

@TestTemplate and @TestFactory methods

In this case, using target=CHILDREN would unlock a new use case, namely to be able to use a different ExecutionMode for the invocations of a test template or the dynamic tests of a test factory than for the test template/factory container node.

@ParameterizedTest
@ValueSource(ints = { 1, 2 })
@Execution(SAME_THREAD) // optional
@Execution(value = CONCURRENT, target = CHILDREN)
void parameterizedTest() {}

@TestFactory
@Execution(SAME_THREAD) // optional
@Execution(value = CONCURRENT, target = CHILDREN)
Stream<DynamicTest> parameterizedTest() {/* ... */}

Related issues

• Order annotation in parametrized tests not respected with concurrent execution #4363
• Optionally run tests within classes with read-write locks concurrently #4346

Deliverables

• Introduce target attribute and evaluate it when computing the ExecutionMode of a child TestDescriptor