Different validation on linkml-validate and linkml-convert --validate

[Silvanoc]

Describe the bug
Validation behaves differently if run directly with linkml-validate or indirectly with linkml-convert --validate.

Additional context
Within the scope of PR #1630 I've been stumbling over some validation errors that where puzzling me. Until I've realized that the code preparing the validation has decisive differences between linkml-validate and linkml-convert --validate, though I would expect them to basically behave the same way.

In the case of linkml-validate the object is loaded by default as a dictionary with load_as_dict(), only if it fails load() will be used and then converted to a dict. That dict will then be validated with iter_validate_dict().

In the case of linkml-convert --validate the object is loaded by default as an object with load(). Then some inferrence is run, if selected (is it needed for the validation? or for something else later on?). Finally the object gets validated, since the option --validate has been passed, with validate_object().

According a Slack message from @pkalita-lbl, I started working with dictionaries instead of object for validation and it helped me getting the option linkml-validate --include-range-class-descendants working. Therefore I assume that I'm probably having the same issue trying to get linkml-convert --include-range-class-descendants working in PR #1630.

IMO the validation mentioned above in linkml-convert --validate should use the same pattern as linkml-validate does. It would result in the same validation results (what probably every user expects) and hopefully help me to get PR #1630 working.