Improve consolidator registration ergonomics: quote-to-trade bar adaptation, registration-time period validation, calendar periods in RegisterIndicator

[jhonabreul]

Description

Consolidator registration on quote-only feeds (forex, cfd) and with mismatched periods fails in ways that are avoidable or needlessly late: type mismatch rejections the engine could adapt, period validation deferred to the first data point (potentially months into a backtest), calendar periods accepted by Consolidate() but not RegisterIndicator, and an NRE on null symbols.

The change:

• SubscriptionManager.AddConsolidator adapts trade bar consolidators to quote-only feeds: a new QuoteBarToTradeBarAdapter collapses each QuoteBar into a mid-point, zero-volume TradeBar. Removal by the user-held consolidator still works.
• QCAlgorithm.RegisterIndicator<T> does the same at the indicator layer (e.g. self.obv(symbol, Resolution.HOUR) on a cfd).
• Fixed time span periods are validated at registration: a 5-minute consolidator on a daily subscription now fails in Initialize with an actionable message instead of at the first bar.
• RegisterIndicator/ResolveConsolidator accept calendar rules (Calendar.WEEKLY, Calendar.MONTHLY, custom), in C# and Python.
• Clearer rejections: the type mismatch error suggests Consolidate(), and a null symbol (e.g. Future.Mapped before the first mapping) throws an ArgumentNullException explaining the likely cause instead of an NRE.

Deferred: single-parameter Python data_consolidated handlers (interop-layer concern), calendar overloads on every indicator helper, and quote-feed adaptation of the C# Consolidate(symbol, period, Action<TradeBar>) overloads.

Related Issue

N/A

Motivation and Context

The engine has all the information to adapt or fail fast at registration, and the late period error can kill a backtest months of simulated time in.

Requires Documentation Change

register_indicator docs can mention calendar periods; the quote-to-trade adaptation is transparent.

How Has This Been Tested?

• New ConsolidatorAutoAdaptationRegressionAlgorithm (C# + Python): adaptation on EURUSD, weekly RSI via calendar rule, registration-time period rejection.
• SubscriptionManagerTests: adapter data flow and removal, period validation cases, null-symbol message, mismatch suggestion.
• AlgorithmIndicatorsTests and PythonIndicatorTests: calendar registration (C# and Python), adapted indicators, updated messages.
• Suites: Tests.Common.Data (905 passed), affected fixtures (448 passed), 60 consolidator/indicator regression algorithms passed.

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>