Remove empty horizon component from irradiance.haydavies

[cbcrespo]

• Closes #xxxx
• I am familiar with the contributing guidelines
• I attest that all AI-generated material has been vetted for accuracy and is in compliance with the pvlib license
• Tests added
• Updates entries in docs/sphinx/source/reference for API changes.
• Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
• New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
• Pull request is nearly complete and ready for detailed review.
• Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

This PR is part of my GSoC 2026 project. One of the goals is to add support for return_components to all diffuse transposition models in pvlib, which currently is supported by some models (e.g. perez) but not others. This parameter allows the user to choose whether they want only the total diffuse irradiance (default), or are interested in the split between different diffuse components (sky diffuse, circumsolar, horizon brightening).

haydavies is one of the models which already supports return_components. However, the model itself supports only sky diffuse and circumsolar components, not horizon brightening. Currently, the function returns a horizon brightening component filled with zeros. As suggested by @adriesse here, I've decided not to include empty components in new additions and so, for consistency, I've also modified haydavies to remove the horizon brightening component.

In addition, I've changed the existing OrderedDict to a dict, as suggested by @kandersolar (see #1684).

The docstrings and the relevant test were also modified accordingly.

[AdamRJensen]

@kandersolar This is technically a breaking change. Do we want a deprecation period (which will slow down the GSoC project a lot - probably not a good reason not to do it)?

[kandersolar]

Do we want a deprecation period

I'd love one, but unfortunately we don't have a good mechanism for deprecating dict/dataframe keys (see #2530). If we go forward with this change, I think all we can do is just do it.

Not related, but fyi: I need to review the discussion about not including empty components, since it's a change in direction and I don't remember the arguments for/against.