Add contract days_to_expiry/dte and interpret Python date/datetime type errors

[jhonabreul]

Description

Python algorithms mix .NET-converted datetime values (self.time, expiries) with pure Python date objects and die on DTE math:

can't compare datetime.datetime to datetime.date
tzinfo argument must be None or of a tzinfo subclass, not type 'CachedDateTimeZone'
type(s) expected

The changes:

• New contract.days_to_expiry(reference) / contract.dte on option and future contracts: whole days to expiry, date parts only. The reference accepts datetime or date from Python and defaults to the contract's current time.
• The datetime-vs-date TypeErrors now get a hint pointing at .date() alignment and days_to_expiry/dte.
• New tzinfo interpreter: datetime.now(TimeZones.NEW_YORK) now explains Lean time zones are not tzinfo and points at ZoneInfo("America/New_York").
• AlgorithmImports now imports ZoneInfo, so the hinted fix works without an extra import.
• New generic-parameter interpreter: the bare type(s) expected error (e.g. RollingWindow[datetime](30)) now explains that Python types cannot parameterize .NET generics and names the alternatives.

Related work: QuantConnect/pythonnet#143 adds datetime/date coercion at the interop layer; the hints here still cover pure-Python mixes.

Deferred (needs interop-layer changes): making RollingWindow[datetime] work, and making Lean time zones directly usable as tzinfo.

Related Issue

N/A

Motivation and Context

DTE filtering is line one of nearly every options/futures selector, and these exact errors are easy to hit and hard to decode.

Requires Documentation Change

Yes: document days_to_expiry/dte and the ZoneInfo availability.

How Has This Been Tested?

• ContractDaysToExpiryRegressionAlgorithm (C# + Python): validates days_to_expiry/dte against manual expiry math; the Python twin passes datetime, date and keyword references.
• OptionContractTests / FuturesContractTests: default and explicit references, plus Python binding tests.
• New/extended interpreter tests using real Python exceptions; negative cases assert unrelated errors are not interpreted.
• Full Tests.Common.Exceptions + Tests.Common.Data.Market namespaces: 211 passed, 0 failed.
• End-to-end Launcher runs: the three failure shapes reproduced verbatim on master, new messages verified after.

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>

[jhonabreul]

Superseded: this surface is already addressed by pythonnet PR #143 (datetime/date coercion at the interop layer). Closing per review.