Add object_type param to named object check

[RNKuhns]

Reference Issues/PRs

Fixes #135

What does this implement/fix? Explain your changes.

Allows users to specify a specific class type to be used in the named object checks (is_sequence_named_objects and check_sequence_named_objects.

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

No

PR checklist

For all contributions

• I've reviewed the project documentation on contributing
• I've added myself to the list of contributors.
• The PR title starts with either [ENH], [CI/CD], [MNT], [DOC], or [BUG] indicating whether
  the PR topic is related to enhancement, CI/CD, maintenance, documentation, or a bug.

For code contributions

• Unit tests have been added covering code functionality
• Appropriate docstrings have been added (see documentation standards)
• New public functionality has been added to the API Reference

[codecov-commenter]

Codecov Report

Merging #136 (9ab5d1a) into main (bd6acb6) will increase coverage by 0.08%.
The diff coverage is 100.00%.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@            Coverage Diff             @@
##             main     #136      +/-   ##
==========================================
+ Coverage   82.35%   82.43%   +0.08%     
==========================================
  Files          31       31              
  Lines        2278     2289      +11     
==========================================
+ Hits         1876     1887      +11     
  Misses        402      402              

Impacted Files	Coverage Δ
skbase/validate/_named_objects.py	100.00% <100.00%> (ø)
...base/validate/tests/test_iterable_named_objects.py	100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[RNKuhns]

@fkiraly this should be good to go besides the fix in #137 that solves the pre-commit.ci failure.

[fkiraly]

I would say that it can also be a tuple of class, this might be useful, e.g., in pipelines

[fkiraly]

I really don't like this additional amount of non-functional code generated from overload, but it's a matter of taste and not a blocker for me...

[fkiraly]

same here

[fkiraly]

Happy to merge.

I would suggest to extend the contract to allow tuples of classes, which it already does anyway (but doesn't say so in the docstring, and doesn't check in the tests).
Why: pipelines can be heterogeneous, and we may like to cover that case.

[RNKuhns]

Good point on tuples. Will update docstring and tests pre-merge.