In BTreeMap::eq, do not compare the elements if the sizes are different.

[zachs18]

Reverts #147101 in library/alloc/src/btree/

#147101 replaced some instances of code like a.len() == b.len() && a.iter().eq(&b) with just a.iter().eq(&b), but the optimization that PR introduced only applies for TrustedLen iterators, and BTreeMap's itertors are not TrustedLen, so this theoretically regressed perf for comparing large BTreeMap/BTreeSets with unequal lengths but equal prefixes, (and also made it so that comparing two different-length BTreeMap/BTreeSets with elements whose PartialEq impls that can panic now can panic, though this is not a "promised" behaviour either way (cc #149122))

Given that TrustedLen is an unsafe trait, I opted to not implement it for BTreeMap's iterators, and instead just revert the change. If someone else wants to audit BTreeMap's iterators to make sure they always return the right number of items (even in the face of incorrect user Ord impls) and then implement TrustedLen for them so that the optimization works for them, then this can be closed in favor of that (or if the perf regression is deemed too theoretical, this can be closed outright).

Example of theoretical perf regression: https://play.rust-lang.org/?version=beta&mode=release&edition=2024&gist=a37e3d61e6bf02669b251315c9a44fe2 (very rough estimates, using Instant::elapsed).
In release mode on stable the comparison takes ~23.68µs.
In release mode on beta/nightly the comparison takes ~48.351057ms.