Improve type safety of Hydra logging configurations

Summary

Hydra currently models both logging configurations as effectively untyped dictionaries:

hydra_logging: Dict[str, Any] = MISSING
job_logging: Dict[str, Any] = MISSING

Model the standard Python dictConfig shape so known fields are validated during composition while supported extension points remain open.

#3066 exposed this gap: Hydra assumes a non-null root, although dictConfig also supports named-loggers-only configurations.

Blocker

This is blocked by OmegaConf #1328, which proposes declarative open structured configs such as @omegaconf.config(struct=False).

Logging handler, formatter, and filter definitions require this combination:

• validate known fields;
• accept handler-specific arguments and custom factory parameters.

The deprecated structured-Dict subclass mechanism tracked by OmegaConf #663 should not be revived.

Direction

After the blocker is resolved:

• use closed structured types for the top-level configuration, root logger, and named loggers;
• use open structured types for handlers, formatters, and filters;
• localize Any to genuine runtime extension points;
• preserve custom classes, () factories, handler-specific arguments, and all existing Hydra logging configurations.

Special keys such as class, (), and . may initially remain open fields validated by Python. Typed aliases for them are outside the initial scope.

Add composition and runtime tests covering built-in configs, named-loggers-only configs, invalid known-field types, custom factories, and arbitrary supported extension arguments.