Add scheduling API conveniences: callable-tolerant rule properties, every-N-days, IANA time zone ids, default time rule

[jhonabreul]

Description

Scheduling API conveniences addressing recurring crash shapes:

• Time/date rule properties are now call-tolerant from Python: self.time_rules.midnight(), noon(), now(), self.date_rules.today(), tomorrow() return the rule instead of failing with 'FuncTimeRule' object is not callable.
• DateRules.Every(TimeSpan): every-N-days rule, anchored at the schedule start (date_rules.every(timedelta(days=5))). Rejects sub-day or fractional-day intervals, pointing at TimeRules.Every().
• TimeRules.At(hour, minute[, second], "Europe/London"): accepts an IANA time zone id where a DateTimeZone was required, with a clear error for unknown ids.
• Schedule.On(dateRule, callback): defaults the time rule to midnight, mirroring universe selection schedules. A time rule (or any non-callable) in the callback slot fails with an explicit "missing callback" error instead of silently scheduling a no-op.

Deferred: DateRules.Every(int) (ambiguous with the Every(DayOfWeek) binding), a minutes= kwarg alias on after_market_open (breaking rename), and ZoneInfo arguments in At() (the string form covers the usage).

Related Issue

N/A

Motivation and Context

Scheduling is one of the most universal APIs, and these exact call shapes are recurring runtime crashes: properties and methods are indistinguishable to Python callers, and the two-argument universe-selection schedule.on(date_rule) teaches a two-argument form that didn't exist.

Requires Documentation Change

The new overloads could be added to the scheduled events documentation.

How Has This Been Tested?

• TimeRulesTests / DateRulesTests: string time zone equivalence and invalid-id error, every-N-days anchoring and interval validation, Python timedelta creation, property-call tolerance from Python.
• ScheduleManagerTests: midnight default (C# and Python callbacks), missing-callback and non-callable guards.
• New SchedulingConvenienceRegressionAlgorithm (C# + Python): asserts exact fire times for the new rules; the Python twin exercises the property-call tolerance. Both pass.
• Scheduling + Python unit suites and related regression algorithms green with CI filters.

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>