Added "Try" Methods and Predicate to Configuration Service

[mdwigley]

Description

This change introduces safe "Try" style registration and unregistration methods to the IConfigService interface and its implementation in ConfigService. The new methods (TryRegisterConfig and TryUnregsterConfig) allow clients to attempt configuration registration and unregistration without exceptions, returning a boolean to indicate success. Additionally, a predicate method IsConfigRegistered was added to check if a configuration type is already registered. The ConfigService class also gained a static helper method, GetInstance, for dependency-injection based construction. Furthermore, base classes for configuration providers were refactored for better separation, and null-handling behavior was improved in FileConfigService to prevent setting null on collection properties.

Related Issue

• Resolves Add "Try" Methods and Predicate to Configuration Service #58

Motivation and Context

The existing registration and unregistration operations throw exceptions on failure, which can complicate client error handling and reduce API usability. Adding safe "Try" methods simplifies client interaction by providing non-throwing options with clear success feedback. The predicate method enables clients to verify registration state before attempting changes. The DI-friendly static construction helper eases integration into dependency injection pipelines. These additions enhance robustness, clarity, and developer experience across the configuration service.

How Has This Been Tested?

The changes were tested with unit tests covering registration and unregistration both in normal and failure scenarios, ensuring the "Try" methods correctly return success status without throwing exceptions. Predicate checks were validated for correct presence reporting of registered types. The static DI construction was tested by initializing the ConfigService with a service collection in sample applications. Refactored provider base class functionality was verified to maintain existing behavior. Null handling in FileConfigService was tested to confirm collections are not set to null erroneously.

Screenshots (if appropriate):

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)
• Asset change (adds or updates icons, templates, or other assets)
• Documentation change (adds or updates documentation)
• Plugin change (adds or updates a plugin)

Checklist:

• I have read the CONTRIBUTING document.
• My change requires a change to the core logic.
  • I have linked the project issue above.
• My change requires a change to the assets.
  • I have linked the asset issue above.
• My change requires a change to the documentation.
  • I have linked the documentation issue above.
• My change requires a change to a plugin.
  • I have linked the plugin issue above.