Implement Factory-Based Subsystem Configuration Registry

# Implement Factory-Based Subsystem Configuration Registry

## Problem

The current `ServerConfig` implementation doesn't properly support extensible visualization configurations for detector components. The initial approach had several limitations:

1. **Rigidly typed configurations**: The system used strongly typed interfaces that couldn't gracefully handle partial or malformed user configurations
2. **No validation mechanism**: Missing properties or invalid values weren't properly detected or replaced with defaults
3. **Limited extensibility**: Adding new configuration types required modifying core service code
4. **No schema or factory pattern**: There was no centralized way to register, validate, and create configuration objects

These limitations would make it difficult for users (firebird/pyrobird operators) to provide custom visualization configurations for detector components.

## Solution

Implement a factory-based configuration registry system with schema registration and validation. This approach enables:

- Registration of configuration schemas with validation and normalization rules
- Handling of partial/malformed user configurations gracefully
- Creation of properly typed configuration objects from user input
- Easy extension with new configuration types without modifying core code

## Implementation Details

### 1. Configuration Schemas

Each configuration type now has a schema that defines:
- Validation logic to check if a config is well-formed
- Default values for all properties
- Normalization logic to handle partial configurations

### 2. Registry Service

The `SubsystemConfigRegistry` service:
- Maintains a registry of configuration schemas
- Provides methods to retrieve, validate, and create config objects
- Normalizes user input against registered schemas
- Emits change notifications when configurations are updated

### 3. Schema Provider Pattern

Each configuration type has a provider that:
- Defines its schema (validation, defaults, normalization)
- Automatically registers with the registry on instantiation
- Handles type-specific validation logic

### 4. Angular Integration

- Added proper module initialization for config schemas
- Implemented reactive components that respond to config changes
- Added APP_INITIALIZER to ensure configs are loaded before the app starts

## Example Usage

Creating UI components that utilize the configuration system:

```typescript
// Get configurations of a specific type
const filterConfigs = configRegistry.getConfigs('RootPipelineTopRemoveList');

// Find a specific configuration
const selectedConfig = configRegistry.getConfigByName('RootPipelineTopRemoveList', 'FarForward');

// Create a new configuration with defaults
const newConfig = configRegistry.createDefaultConfig(
'RootPipelineTopRemoveList',
'My Custom Filter'
);
```

UI components can create dropdowns that show available configurations and let users select which visualization settings to apply.

## Testing

Added comprehensive tests for:
- Schema validation and normalization
- Configuration creation and retrieval
- Registry functionality

## Breaking Changes

This implementation replaces the previous strongly-typed configuration approach with a more flexible schema-based system. Components that directly accessed configuration objects will need to be updated to use the registry API.