Require VarULE concrete fns to behave the same as trait fns

[sffc]

I was wanting to call some of these fns in a const context, which I can do if they are concrete fns instead of trait fns, at least until rust-lang/rust#143874 lands. WDYT about adding the safety requirement in this PR?

I updated all of the concrete impls, but not sure what to do about the derive impls.

[Manishearth]

I don't think this is an appropriate use of a safety invariant, and we explicitly violate it in a few cases so the invariant as written is simply wrong.

Users of this trait in contexts where the invariants are relevant should be careful when calling functions in non-generic contexts that the dispatch works correctly; this is part and parcel of writing correct unsafe code and not something we need to cover explicitly.

I also don't see what this achieves. Correct me if I'm wrong: Is your goal to be able to call the "concrete const" versions of these functions and assume they have the same behavior? If so I think it makes more sense to document a "safety usable invariant" on the concrete functions where you say "can be guaranteed to have identical behavior to <Self as VarULE>::foo().

[sffc]

we explicitly violate it in a few cases

Citation?

...
I also don't see what this achieves
...

Did you see the latest change in #7394?

I have a macro_rules that calls concrete functions (since that's all you can do in const), requires a trait bound to be satisfied, and uses that trait bound to justify a generated unsafe block. It makes the macro 100% safe to call.

You expressed openness (but distaste) to using trait safety requirements to require certain behavior on concrete functions in a similar context previously: #6576 (comment)