Implement named (item) closures

[msullivan]

We should probably be able to have named functions that can close over their environments.

I think we definitely want named copying closures. There shouldn't be anything fundamentally difficult about this, although these are items that behave differently that other items, and thus will be a bit annoying.

Named aliasing closures are trickier, since their upvars can get deinitialized. Probably the right solution, if we want them, is to check that their upvars are initialized when the name is referenced. (Graydon's proposal suggested doing the capture when the name is referenced for both aliasing and copying closures; I think that doing it for copying closures is extremely counterintuitive since it would be behaving substantially different from assigning it to a variable manually.)

Making the items be able to take type parameters might also be a bit fiddly, as the function will need to pull type parameters from both the closure and the arguments.

[marijnh]

I initially figured this wasn't a very necessary feature, but it is almost impossible to construct recursive closures using the current system. That seems a good motivation for item closures.

[nikomatsakis]

I am of two minds. It is true that recursive closures are almost impossible, which is a shame. On the other hand, getting the semantics of when the capture code occurs is a pain. In practice, if I want recursive closures, then I just create a record for the data I need and make an impl for it. Not sure if this is an acceptable workaround.

[nikomatsakis]

but I'd be inclined to close this bug for now. I don't feel like it's a burning problem.

[catamorphism]

heh, I assigned this to myself? If it's not wanted all that badly, I'm happy to not do it, though ;-)