Refactor exception hierarchy for library discovery implementations

[mxr576]

Problem

The current single exception class \Drupal\swagger_ui_formatter\Exception\SwaggerUiLibraryDiscoveryException was adequate when the module had only one discovery implementation. However, with the introduction of a second discovery implementation (as discussed in PR #115 review, this approach has several issues:

• Implementation detail leakage: The shared exception exposes internal details from multiple implementations
• Mixed concerns: Error codes and messages from different discovery implementations are mixed together in a single class
• Tight coupling: Implementations are forced to use error codes that may not be relevant to their specific use case

While some error scenarios are genuinely common (e.g., SwaggerUiLibraryDiscoveryException::CODE_REQUIRED_FILE_IS_NOT_FOUND), most error conditions are implementation-specific and should be handled as such.

Proposed solution

Interface restructuring:

• Keep the SwaggerUiLibraryDiscoveryExceptionInterface as a marker interface
• Move the interface to the \Drupal\swagger_ui_formatter\SwaggerUiLibraryDiscovery namespace for better organization

Method-specific exceptions:

• Create dedicated exception interfaces for each method in SwaggerUiLibraryDiscoveryInterface:
  • Exception interface for libraryDirectory() failures
  • Exception interface for libraryVersion() failures
• This allows implementations to throw specific exceptions while maintaining a common contract

Breaking change:

• Remove the legacy SwaggerUiLibraryDiscoveryException class
• This change requires a major version bump (5.0.0) as it's a breaking change
• Exception deprecation is complex, which is why this refactoring was deferred to 5.0.0

Benefits

• Better encapsulation: Each implementation can define its own error scenarios
• Cleaner interfaces: Method-specific exceptions make error handling more predictable
• Improved maintainability: Adding new discovery implementations won't pollute existing exception classes
• Type safety: Consumers can catch specific exception types based on the operation being performed

This refactoring aligns with the principle of interface segregation and provides a more robust foundation for future discovery implementations.