Allow overriding the default file name pattern for Discovery

[johnhunt-lc]

This PR adds the option to pass in a namePatterns array of patterns to match against filenames, overriding the default '*.php' pattern that was previously hardcoded.

Motivation and Context

It would be useful to be able to either limit further, or expand, the scope of files matched by discovery. The specific cases I've run into that require this functionality are:

• excluding some tools depending on environment context
• matching code convention for legacy projects that use alternative file extensions for php class files (*.inc for example)

How Has This Been Tested?

I have tested this in a php application that uses .inc files to store classes, and have added additional unit tests. I haven't tried it in other contexts.

Breaking Changes

This should not affect existing code.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[chr-hertel]

Hey @johnhunt-lc, wasn't aware of that use case, but recall seeing that convention years ago. Thanks for the patch, minor comments tho.

[chr-hertel]

Using a default here would ease the change:

Suggested change

	public function discover(string $basePath, array $directories, array $excludeDirs = [], ?array $namePatterns = null): DiscoveryState
	public function discover(string $basePath, array $directories, array $excludeDirs = [], array $namePatterns = ['*.php']): DiscoveryState

[johnhunt-lc]

I was batting around different ideas for this. $namePatterns gets passed through quite a few different functions, and I originally specified the ['*.php'] default for each one, but I realized that was scattering hardcoded defaults everywhere so I switched to default null in all the functions that pass it along, and just set the default in the ternary below.

I agree that I prefer having the default in the params instead. Would you rather I:

• set a class const and use it for the default in all functions that use this argument?
• hardcode this in all of them?
• set it here, make the rest default to null, make this nullable, and handle nulls in the function logic?
• some other 4th thing I haven't thought of?