Improve the fn pointer types

[nikomatsakis]

The current function pointer types have some downsides:

1. They assume that all functions are static code that lives forever. This isn't true for JITs or DLLs.
2. They are always non-nullable, safe pointers. This may not be what you want -- particularly the nullable aspect. This is connected to the previous point, because it implies that there is no place to attach a lifetime in the current syntax.

This is a "postponement issue". There have been various RFCs aiming to improve this:

• Function pointer lifetimes #252 -- a fairly straight-forward scheme to add lifetimes to fn types.
• Make function pointer types look like borrowed pointer types for forwards compatability #883 -- a simple scheme to change the syntax of fn to &'static fn for forwards compatibility.
• RFC: Function pointers reform #996 -- a more involved scheme which introduced a kind of unsized type.

It should be possible to adapt these schemes backwards compatibly.

[CloudiDust]

I am currently of the opinion that if function pointers are not considered pointers by the language, then we'd better call them something else, like "function handles". This can be the first step towards improving fn types.

"Function pointers are not considered pointers" feels like a flaw in Rust's design, but "function handles are not considered pointers" doesn't.

Also, if later "true" function pointers are introduced, we need to disamiguate fns and "true" function pointers. Renaming fns to "function handles" is a good way to do so.

I wonder if such a renaming proposal should be an RFC? :)

[jarcode-foss]

We still need a way to specify lifetimes for fn types, and I don't feel like representing function pointers as actual borrows in Rust is really nessecary. I favour an approach similar to #252 -- fn 'a (A, B) -> R, where if the lifetime is omitted, 'static is assumed.

However, when it comes to DLL loading (see #661), lifetimes of functions that are being used outside of the loaded code will be bound by the lifetime of the library (handle) itself, which the loaded code is unaware of. In this sense, 'static' in all the library code refers to the lifetime of the libray.

This means that when symbols are resolved from a DLL, a 'static lifetime needs to be translated into 'a, where 'a is the lifetime of the library handle. This also means the definition of static lifetimes in Rust may need to be changed.

Additionally, there should be some similar way to specify lifetimes for Fn closures.