feat(discovery): add support for dynamic path exlusion

[innocenzi]

This pull request adds support for dynamically excluding paths from being discovered:

new DiscoveryConfig(
    locations: [
        new DiscoveryLocation('Module\\', base_path('src/Modules')),
        new DiscoveryLocation('Infrastructure\\', base_path('src/Infrastructure')),
        new DiscoveryLocation('Integrations\\', base_path('src/Integrations')),
    ],
)->skipUsing(static function (string $input) {
    if (str_ends_with($input, needle: 'Test.php')) {
        return true;
    }

    if (str_ends_with($input, needle: 'Pest.php')) {
        return true;
    }

    return false;
});

It also includes another fix for when Tempest scans a Pest test file:

When encountering a test or Pest.php file, class_exists or new ClassReflector throws because it autoloads the file.

[github-actions]

Benchmark Results

Comparison of fix/discovery/pest against 3.x (d53cd8d4a1c4d1c816e3b27db88a1cfa433e4ea6).

Open to see the benchmark results

Benchmark	Set	Mem. Peak	Time	Variability
QueryExecutionBench(benchExecuteInsert)	-	4.239mb -0.81%	7.797μs -27.33%	±1.18% -32.44%
QueryExecutionBench(benchFetchAll)	-	4.239mb -0.81%	41.144μs -8.71%	±0.70% -47.41%
QueryExecutionBench(benchFetchWithBindings)	-	4.239mb -0.81%	14.162μs -20.68%	±1.06% -63.96%

_{Generated by phpbench against commit fc05662}

[aidan-casey]

@innocenzi - why don't we just add exclusion rules and include a couple smart defaults?

[innocenzi]

The discovery config already has something similar, but nothing dynamic, I assume for performance.

I think adding static closure support would be fine too, but in this specific case, we already have a workaround for Pest within Tempest, and I'm extending it for outside of Tempest, I don't think all Pest users should manually have to debug that weird error

[innocenzi]

@aidan-casey I added the functionality anyway because it's useful!