fix: remove hours limit for parseDuration

[limkhl]

Closes #5416

As mentioned in the issue, I reviewed the Temporal.Duration spec to align the behavior. It seems that the hours value can go up to 130 and beyond, with no explicit maximum limit. Therefore, I’ve adjusted the maximum value to be Infinity.

The previously invalid case P18Y7MT30H15S is valid in Temporal spec, as it returns:

{
    years: 18,
    months: 7,
    weeks: 0,
    days: 0,
    hours: 30,
    minutes: 0,
    seconds: 15
}

As a result, I’ve updated the test case accordingly.

Additional Notes: Currently, only the hours property has had its maximum value limit removed, but properties like years, months, minutes, and seconds should also not have maximum limits. To fully align with the Temporal.Duration specification, I think it’s necessary to remove the maximum value restrictions for all these properties.

✅ Pull Request Checklist:

• Included link to corresponding React Spectrum GitHub Issue.
• Added/updated unit tests and storybook for this change (for new code or code which already has tests).
• Filled out test instructions.
• Updated documentation (if it already exists for this component).
• Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

🧢 Your Project:

[snowystinger]

seems fine on the surface, will double check with others if there was a reason we did this internally

[snowystinger]

message from original implementer

The limits incorporated were a result of trying to adhere to the ISO8601 standards for a Duration string
My understanding is that based on ISO8601 standards, date and time values can’t exceed their moduli - so a duration string of P18Y7MT30H15S would not technically be a valid in ISO8601 standards
However based on the temporal spec (and the example you shared that the spec accepts overflow), I did a quick test and navigated to https://tc39.es/proposal-temporal/docs/duration.html#new-Temporal-Duration and input the following in the browsers console: Temporal.Duration.from('P18Y7MT30H15S') and no errors are thrown. So that would suggest to me that the temporal spec does indeed accept overflow, despite ISO8601 standards suggesting otherwise

Seems like there was a discrepancy in the specs, but I think we're ok to go ahead with this, though we should really do it for all the fields asap, otherwise we're going to have a weird state in the API during the transition