Remove legacy discovery tools list_estimators, search_estimators in favour of new tools query_registry, describe_component

[Shashankss1205]

Reference Issues/PRs

Fixes the legacy discovery tool clutter by removing redundant interfaces. fixes #461

What does this implement/fix? Explain your changes.

This pull request completely removes all remaining occurrences and routing of the legacy discovery tools (list_estimators, search_estimators, describe_estimator, and get_available_tags) from both the server routing layer and internal tool implementations.

Specifically:

• Removed legacy routes from server.py and app.py.
• Renamed describe_estimator.py to describe_component.py to match the unified describe_component_tool name.
• Updated all existing unit tests in tests/test_core.py and tests/test_discovery_consolidated.py to verify query_registry_tool and describe_component_tool pagination, task filtering, and boundary validation.
• Updated user documentation in README.md, docs/source/implementation.md, and docs/source/usage-examples.md.
• Refactored examples/01_forecasting_workflow.py and examples/02_llm_query_simulation.py to showcase the unified API design.

Does your contribution introduce a new dependency? If yes, which one?

No, this contribution does not introduce any new dependencies.

What should a reviewer concentrate their feedback on?

• Verify that the query_registry and describe_component routes work perfectly under all conditions.
• Confirm that no legacy names or modules are imported or used in production pathways.

Any other comments?

The entire codebase is fully formatted and linted via ruff. All 174 test cases pass cleanly under make check.

PR checklist

For all contributions

• I've added unit tests and made sure they pass locally (make check).
• I've added the tool to the online documentation in docs/source/.
• I've updated the existing example scripts or provided a new one to showcase how my tool works in examples/.

[fkiraly]

Overall, this looks like an improvement.

However, can you please make sure to include docstrings to all important functions and classes? Please have a look how sktime does this. Preferably in the same numpydoc adjacent style that sktime uses.

Otherwise, it becomes really hard to review changes, especially if they are subtle changes.

E.g., I have the question what the new target variable means and which values it can assume, but there is no piece of documentation that would tell me.

[Shashankss1205]

@fkiraly thanks for the feedback, I will try updating all of the PRs with the suitable doc strings to let the maintainers understand the pieces of code easily...