Support custom option chain provider for options universe generation

[jhonabreul]

Description

Adds support for sourcing option chains from a custom IOptionChainProvider during universe generation, mirroring the existing futures-chain-provider support in FutureChainSymbolProvider:

• New OptionChainSymbolProvider (options generator project) instantiates an IOptionChainProvider through the Composer when the universe-option-chain-provider config is set, the same way FutureChainSymbolProvider does for futures.
• Its GetSymbols() override makes a single GetOptionContractList call with a tickerless dummy symbol carrying the generator's security type and market, fetching the contracts of every canonical the provider finds instead of discovering canonicals from the data folder zip files.
• The result is filtered to the generator's security type and market, expired contracts are dropped, and chains are grouped by canonical with the same ordering as the file-based path.
• With no provider configured, or when the provider returns nothing, behavior is unchanged: chains are read from the data folder zip entry names via the base ChainSymbolProvider.
• ChainSymbolProvider is now abstract and purely file-based, and DerivativeUniverseGenerator.GetSymbols() is abstract, with each generator creating its own chain symbol provider (OptionsUniverseGenerator → OptionChainSymbolProvider, FuturesUniverseGenerator → FutureChainSymbolProvider).

Related Issue

N/A

Motivation and Context

Allows generating universe files when the price data files for the processing date are not on disk, by fetching the chains from a custom provider (e.g. backed by a live data store) instead.

Requires Documentation Change

No

How Has This Been Tested?

• Full test suite passes: 19/19.
• The custom provider path is exercised through the concrete provider implementation's own test suite.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance. Please add associated performance test and results)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>