const_eval::cast_const should use target's int/uint types for isize/usize

[pnkfelix]

Spawned off of PR #23863, see discussion here

    define_casts!{
        // FIXME: This should probably be using the target's int-type, not he host's.
        ty::ty_int(ast::TyIs) => (isize, const_int, i64),
        ty::ty_int(ast::TyI8) => (i8, const_int, i64),
        ty::ty_int(ast::TyI16) => (i16, const_int, i64),
        ty::ty_int(ast::TyI32) => (i32, const_int, i64),
        ty::ty_int(ast::TyI64) => (i64, const_int, i64),
        // FIXME: This should probably be using the target's uint-type, not he host's.
        ty::ty_uint(ast::TyUs) => (usize, const_uint, u64),
        ty::ty_uint(ast::TyU8) => (u8, const_uint, u64),
        ty::ty_uint(ast::TyU16) => (u16, const_uint, u64),
        ty::ty_uint(ast::TyU32) => (u32, const_uint, u64),
        ty::ty_uint(ast::TyU64) => (u64, const_uint, u64),
        ty::ty_float(ast::TyF32) => (f32, const_float, f64),
        ty::ty_float(ast::TyF64) => (f64, const_float, f64)
    }

[pnkfelix]

(I think the only tricky part about this is determining if there is a good regression test to catch this bug; obviously it will only be caught in cross-compilation contexts.)

[pnkfelix]

Semi-ironically, I think this bug might be what is blocking PR #23841 from landing.

(If true, then the only "tricky part" referenced above has actually already been accomplished.)

[pnkfelix]

see also #13768 (which #23863 does not completely address; there is clearly still some corner cases to address in the ExprCast logic).

[pnkfelix]

cc #23897