chore(chain): deprecate CanonicalIter, and ChainOracle trait

[oleonardolima]

Description

As both CanonicalIter and ChainOracle trait are being removed/replaced in #2038, and they're public types, we should deprecated them in a 0.23.x release in case any user does use them directly.

Notes to the reviewers

It's simply deprecating CanonicalIter and ChainOracle trait.

Changelog notice

### Changed
- `CanonicalIter` and `ChainOracle` are planned to be removed in a future release, therefore have been deprecated.

Checklists

All Submissions:

• I followed the contribution guidelines

[evanlinjin]

I'm wondering whether it really makes sense to deprecate things that we still rely on.

[oleonardolima]

I'm wondering whether it really makes sense to deprecate things that we still rely on.

I think it's the right approach, as CanonicalIter and ChainOracle are currently public types some user can be relying on them for some reason, and it's good to deprecated them as a notice that's planned for removal/migration.

[luisschwab]

ACK 9286a90

[evanlinjin]

I don't think this is the right use of #[deprecated]. RFC 1270, which introduced #[deprecated], states its purpose is to let authors evolve APIs "while giving users enough time to react" — with the note field intended to describe "what to use instead." The design assumes a migration path exists at the time of deprecation. Here, the replacements (CanonicalTask, ChainQuery) don't exist in 0.23.x, so there's nothing for users to react to other than upgrading to a different major version.

A few concrete issues:

• The crate itself needs #[allow(deprecated)] in 5 places to compile cleanly. When you have to suppress your own deprecation warnings throughout the same crate, it's a strong signal the deprecation is premature for this release line.
• Every downstream consumer of 0.23.x will get warnings they cannot resolve without a major version upgrade. That's noise, not guidance.
• The deprecation messages link to PR #2038 on master — that's not useful context for someone pinned to 0.23.x.

If the goal is to communicate that these APIs are going away, a doc comment note ("This will be replaced by X in version Y") or a mention in the release notes/changelog would achieve the same thing without polluting builds with unresolvable warnings.

[oleonardolima]

As explained in the comment above, and discussed in the last dev call we don't need to deprecate these fields.