Check if we can get away with making `fn()` conflict with `&T`

[hanna-kruppe]

There's the idea that the fn(...) -> R types should be unsized types (like extern type) and function pointers should be proper pointers (e.g. &'a fn()). On its face this appears backwards incompatible in ways editions can't paper over, e.g. if we desugar fn() to &'static fn() in 2015 these two impls would suddenly start conflicting:

trait Foo {}
impl<'a, T: ?Sized> Foo for &'a T {}
impl Foo for fn() {}

@eddyb wants to try implementing it quickly and hackily it to see what breaks:

I think we can do this in type unification, and treat fn() like &SomeLibCoreLangItem there, without changing fn() itself

[eddyb]

I doubt we can change Rust 2018 at all now, but we should be gathering data on coherence/type inference (given this rule), across the ecosystem. cc @nikomatsakis @aturon @Centril

[petrochenkov]

cc rust-lang/rfcs#996 (the last iteration of the relevant RFC)

[Centril]

Removing C-future-compatibility since that should be used to track actual C-future-compat lints that have been implemented.