Remove repr-lookup attempt in derive expansion

[pnkfelix]

Spawned off of #24270, in particular this discussion: #24270 (diff)

The new code for deriving(PartialOrd) attempts to look up if there is a repr attribute on the enum that is driving the deriving expansion, because we need (at least) to incorporate knowledge of whether the discriminant is meant to be interpreted as a signed integer or an unsigned one (since the current intrinsic always returns a u64 today).

However, the look up may be fragile, since @sfackler points out that a later pass of expansion could add the repr that we are seeking.

There are a number of different ways to solve this problem (see the linked discussion for some of them).

[pnkfelix]

I do not see this as a terribly high priority item.

Exposing the problem requires injecting a repr attribute at a later pass of expansion, but I am not sure there are currently any instances of expansions that do this.

(Also, you would need to be explicitly assigning discriminant values where the sign-bit could be misinterpreted in such a test case. Which certainly can happen -- I'm just saying that you'd need quite a confluence of events to actually witness the bug.)

[pnkfelix]

triage: P-low

[Mark-Simulacrum]

I think this is largely unsolveable to the extent that derives are always going to be less than perfect (we don't know enough at expansion time). In particular, we hit this issue with repr(packed) types and related desire for the type to be Copy...

I'm going to close this issue as I don't think it's worthwhile to track this.