Decide where helper functions that belong to one class should live #1054

Helpers that belong to a single class are currently written in two ways:

• Private methods, in most of the library, including helpers that don't use self, for example WoE._calculate_woe, SelectByInformationValue._calculate_iv, RelativeFeatures._raise_error_when_zero_in_denominator and DatetimeFeatures._check_index_contains_na.
• Module-level private functions, in a few transformer modules: _gpm_fast (encoding/similarity_encoder.py), _hash_seeds (imputation/random_sample.py), _pandas_version and _get_numpy_reducer (creation/math_features.py).

The discretisation helpers added during the narwhals migration were module-level functions. #1053, #1040 and #1042 move them into their classes as private methods, to match the current convention.

We should settle on one convention and record it in AGENTS.md. Options:

1. Private method (current convention). The helper lives with its class and subclasses can override it. When the helper doesn't depend on the object's state, it still receives self without using it.
2. @staticmethod. Same as 1, but Python doesn't pass the instance, so there is no self parameter. It signals that the helper belongs to the class but doesn't need an instance. It can still be overridden and is called as self._name(...). Not used anywhere in the library yet.
3. Module-level private function. Signals that the helper doesn't depend on any class. Several classes in the module can share it and it can be tested on its own, but subclasses can't override it.

Helpers shared across modules (dataframe_checks.py, variable_handling, _check_init_parameters) are out of scope: they already live in dedicated modules.