Fix purge requests without a creation start time

[andystaples]

Summary

• default purge_instance_history_by to datetime.min when created_time_from is omitted
• serialize years below 1000 with four digits across platforms
• add regression coverage for the generated purge URL

The Durable extension intentionally requires createdTimeFrom so a bare collection DELETE cannot become an accidental unfiltered purge. The SDK method explicitly exposes created_time_from as optional, so it now translates that omission into an explicit lower bound instead.

Fixes #560
Fixes #533
Fixes #470

Testing

• python -m pytest -q tests\models\test_DurableOrchestrationClient.py tests\models\test_RpcManagementOptions.py
• python -m flake8 azure\durable_functions\models\DurableOrchestrationClient.py azure\durable_functions\models\RpcManagementOptions.py

[cgillum]

It's my understanding that datetime.min results in a date like 0001-01-01T00:00:00.000000Z. One concern I have is whether all the backends are able to correctly interpret such an early date. Some backends, like MSSQL, are sensitive about date ranges and might choke on this. Consider whether something like 2000-01-01T00:00:00.000000Z would be better.

[cgillum]

nit: I don't think purging "Running" instances is actually valid, so I suggest that these tests use a valid status filter to avoid confusing readers (or agents) about what a valid use case for purge is.

[cgillum]

One risk from this change is that an API call that previously returned a 400 now attempts to delete everything, which can be quite destructive. I'm not as familiar with the original issue, but we should think carefully about whether this risk is worth the benefit.