By removing `composer/package-versions-deprecated`, and instead using `composer-runtime-api:^2`,
we both get rid of a dependency, and obtain better type information from our lookup.

This also coincidentally drops a bunch of inline `@psalm-suppress` statements.

…PHPUnit version

Since PHPUnit 8.0, `expectException()` has proper type annotations, and I even patched `createMock()` and similars
so that proper generic types are inferred.

These stubs are therefore no longer necessary.

At this point, these classes are mostly "OK" in PHPUnit, starting ~8.5.1:

* `PHPUnit\Framework\MockObject\Builder\InvocationMocker` (now declares missing types)
* `PHPUnit\Framework\MockObject\MockObject` (still uses `@method` at class level, but that works)
* `PHPUnit\Framework\MockObject\MockBuilder` (fully templated)
* `PHPUnit\Framework\TestCase` (except for `prophesize()`, which was later removed)

Adding a conflict to PHPUnit earlier than 8.5.1, to make
the phpunit version requirement more clear.

Starting with PHPUnit 8.0, assertions have decent assertion metadata declarations
on most methods.

This also removes assertion tests, simplifying the test suite further.

Starting from Prophecy 1.20.0, methods have proper generic types declared.

Adding a conflict to prevent earlier prophecy versions from being co-installed.

Refs:

* phpspec/prophecy@e4d39b1
* phpspec/prophecy@0bb033e
* phpspec/prophecy@4506935

Starting from `phpspec/prophecy-phpunit:2.3.0`, the out-of-the-box `ProphecyTrait` is well typed.

Ref: phpspec/prophecy-phpunit@ba6dc1b

…ributes

…mmitted

Ref: sebastianbergmann/phpunit@893c4dd

…deception-psalm-module`

These packages are runtimes that invoke `psalm/plugin-phpunit` via `exec()`, without sharing codespace with
it, and therefore are safe to externalize elsewhere.

We can't afford keeping these dependencies co-located with the main `composer.json` / `composer.lock`, as
they conflict with non-dev dependencies that we want to explicitly test against.

While `psalm/codeception-psalm-module` is a good idea in theory,
in practice, Gherkin scenario steps as a composer dependency are really (REALLY)
hard to distribute and maintain together with a test suite.

This move replaces the external dependency with a local one, with the
test runner mostly staying out of the way, and test logic all implemented
in the `Context` class we wrote ourselves.

The main aim is to improve atomicity of changes on the test suite itself.

Ref: psalm/codeception-psalm-module#54

…ed by @danog

Ref: #149 (comment)

Implemented support for `#[Test]`, `#[DataProvider]`, `#[Before]` attributes, cleaned up old PHPUnit/Prophecy support