docs(time_feature): clarify get_seasonality returns calendar defaults

[abhu85]

Summary

This PR addresses the concern raised in #3278 that the get_seasonality function name is misleading.

The function name suggests it detects or estimates seasonality from data, but it actually returns predetermined calendar-based heuristics (e.g., hourly -> 24, monthly -> 12). Users may reasonably assume some form of data-driven inference is taking place, which is not the case.

Changes

Added comprehensive documentation to both get_seasonality and DEFAULT_SEASONALITIES that explicitly clarifies:

• The function does NOT analyze time series data
• It returns static calendar conventions (not detected seasonality)
• Values are used for MASE scaling, seasonal naive baselines, etc.
• The returned value should not be interpreted as detected seasonality

Why Documentation Instead of Renaming?

After reviewing the codebase, I found get_seasonality is imported and used in 20+ locations across evaluation metrics, model implementations, and tests. Renaming would be a breaking change affecting many users.

The documentation approach:

• Zero breaking changes
• Clearly communicates the function's behavior
• Follows NumPy-style docstring conventions
• Includes examples showing expected behavior

Test Plan

• All 26 existing seasonality tests pass
• All 4 doctests in the updated module pass
• No functional changes - only documentation added

pytest test/time_feature/test_seasonality.py -v  # 26 passed
python -m doctest src/gluonts/time_feature/seasonality.py -v  # 4 tests passed

Fixes #3278

[abhu85]

Friendly ping for review. This is a documentation-only change addressing the concern in #3278 that get_seasonality name is misleading - clarifies it returns calendar defaults, not detected seasonality.