Allow RelativeDailyVolume to be warmed up through a user-defined WarmUpPeriod

[DG47]

Description

RelativeDailyVolume did not implement IIndicatorWarmUpPeriodProvider, so WarmUpIndicator always skipped it with the warning described in the issue and there was no way to warm it up, even when the user knows how many bars the indicator needs at the resolution they feed it with.

This PR makes RelativeDailyVolume implement IIndicatorWarmUpPeriodProvider with a settable WarmUpPeriod that defaults to 0:

• With the default value nothing changes: WarmUpIndicator requests no history and the indicator is left as it is. The RDV() helper does not take part in automatic indicator warm up, so that behavior is unchanged too.
• When the user sets it (rdv.WarmUpPeriod = 3 * 390 / rdv.warm_up_period = 3 * 390 for three days of minute bars), WarmUpIndicator warms the indicator up with that many bars.

The number of data points the indicator needs still depends on the resolution and on the market hours of the security, which is why it is not derived from the period automatically (see the reasoning in #7344). The property documentation explains this.

Related Issue

Closes #8629

Motivation and Context

Users could not warm up RelativeDailyVolume at all. Letting them define the warm up period themselves gives them a way to do it without LEAN having to guess the bar count.

Requires Documentation Change

The indicator reference for Relative Daily Volume could mention that WarmUpPeriod must be set explicitly for WarmUpIndicator to warm it up.

How Has This Been Tested?

Added to RelativeDailyVolumeTests:

• WarmUpPeriodDefaultsToZeroAndSkipsWarmUp: default WarmUpPeriod is 0, WarmUpIndicator leaves the indicator untouched.
• WarmsUpWithUserDefinedWarmUpPeriod (minute: 3 × 390 bars, hour: 3 × 7 bars): after WarmUpIndicator the indicator is ready, has processed exactly WarmUpPeriod samples and has a non-zero value.

Ran the RelativeDailyVolumeTests fixture locally (macOS arm64, .NET SDK 10.0.401): 14 passed, 1 skipped (WarmUpIndicatorProducesConsistentResults, skipped by design when WarmUpPeriod is 0). AlgorithmIndicatorsTests was also run; the only failures are the Python IndicatorHistory tests, which fail in this environment because pandas is not installed (PandasConverter type initializer), unrelated to this change.

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>

[Martin-Molinero]

Thanks!