Make some NullablePointer enums FFI-compatible with the base pointer type.

[luqmana]

This slightly adjusts the NullablePointer representation for some enums in the case where the non-nullable variant has a single field (the ptr field) to be just that, the pointer. This is in contrast to the current behaviour where we'd wrap that single pointer in a LLVM struct.

Fixes #11040 & #11303.

[brson]

This may be a bigger problem that calls for a more structured solution. In particular, I think we are going to have this exact same problem again with Box being a struct, not a pointer. I wonder what @nikomatsakis's thoughts on this are.

[nikomatsakis]

r+ modulo nits.

[jld]

I've looked over the patch but haven't reviewed it in detail; it looks reasonable, although it would be nice if there were a way to avoid copying st.fields.len() == 1 into so many places. f+

Also, it's been long enough since I touched this that I don't remember what state the FFI-safe-type lint pass is in with respect to allowing Option<&T> and similar without allowing other non-#[repr(C)] enums, but that might be worth looking at.

[luqmana]

@jld I thought about adding another case to Repr but decided against it since there would only be a little different compared to the NullablePointer case.

[nikomatsakis]

@luqmana actually, I think I might prefer to see another case: StructWrappedNullablePointer vs RawNullablePointer or something like that. One consequence is that you could not fail to forget a case. Given that the merge failed, I'd like to change my r+ to r- and request that change. :)

[nikomatsakis]

@luqmana any idea what's the deal with those Travis CI failures?

[nikomatsakis]

Giving r+ in any case, I guess we'll see if those are real or not.