Fix price shifts around futures rollover date

[jhonabreul]

Description

This fixes price shifts around futures rollover dates by properly detecting date changes at exchange time zone and emitting correct new tradable date events at correct times for proper symbol mappings. This allows for the SubscriptionDataReader to better detect a symbol mapping and update the data enumerator source file as needed, potentially keeping the current date but changing files if the symbol has been changed.

This is achieved with the new helper DateChangeTimeKeeper class, wich keeps time both in data and exchange time zones, advancing time as requested (either by trying to jump to the next tradable date or just advancing until a given time) and stopping to emit a new exchange date if one is found.

Notes:

• Data points increase and stats change in some algorithms is due to a change made in SubscriptionRequest: now it is using the BaseDataRequest.ExchangeHours to generate the tradable dates enumerable, instead of using Security.Exchange.Hours. For open interest data, the BaseDataRequest class overrides the exchange hours and uses AlwaysOpen and, to be consistent, the derived class should use that as well.
  • See https://github.com/QuantConnect/Lean/pull/5207 and https://github.com/QuantConnect/Lean/pull/6186
• The changes to the ContinuousContractUniverse class also affect some algorithm data points count: now considering extended market hours (is set, from config) for the trigger dates (#7997)

Related Issue

Closes #7868 Closes #7997

Motivation and Context

Requires Documentation Change

How Has This Been Tested?

• Unit tests
• Regression algorithms (new and exisiting)

Types of changes

• [x] 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:

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