Policy for assumptions about the size of `usize`

When in the course of human rusty events, something in core or std depends on the actual width of usize/isize, there are currently (at least) two policies in place:

1. Conservatively assume that usize may be as narrow as 8 bits.
   • example: usize: From<u8> + !From<u16>
2. Liberally assume that usize is at least 32 bits wide (as it is on all current officially supported platforms).
   • example: Range<u32>: ExactSizeIterator

Let me know if I missed any other corners of the standard library which make assumptions (identical to one of these or not).

As these policies are in conflict, it seems like one or both of them should be changed. In principle, we can't remove trait implementations from Range<u32> and the like, so we could just declare target_pointer_width-liberalism to be the law of the land. However, this will make it difficult to port Rust to a 16-bit system. In doing such porting, trait implementations like From<u32> for usize and ExactSizeIterator for Range<u32> would need to be gated by a #[cfg]. But, this would make it difficult to port Rust code from, say, a 32-bit target to a 16-bit target, because some code would stop compiling (N.B. this is already potentially the case, because literals given for enum variants are interpreted as isize literals).

So, what should we do?

No files, tests, or entry points are named. Start by reviewing the two conflicting usize/isize width policies and their cited examples, then trace other standard-library assumptions about target_pointer_width. Done means reaching and documenting a decided policy for current targets and possible 16-bit ports.