Provide more information about disjoint capture in closures and migration instructions

[roxelo]

This PR adds additional information about disjoint capture in closures such as changes in semantics and migration instructions.

r? @nikomatsakis

Closes #241

[ehuss]

I feel like it would be nice to have a discussion in these sections about what the idiomatic code would look like in 2021. Are people expected to write let _ = &px; under normal circumstances? Or is there another way this example could be cleanly written in 2021?

[roxelo]

Yes, the expectation is that they would write let _ = &px;.

Any thoughts @arora-aman?

[arora-aman]

We don't usually expect users needing to use let _ = &px in a usual case.

However we should probably add a section saying that this feature/edition 2021 might increase the sizes of their closure and if they are working in a memory critical codebase they can use -Zprofile-closures to get an idea of the effect on the size of closures. The profile dumped by -Zprofile-closures contains the size of the closures before and after the edition/feature along with where in the sourcebase the closure is located. In the case where a closure isn't benefiting from disjoint capture they can force the variables to be completely captured similar to technique used for migration within the closure body.

let _ = &var;
let _ = (&var1, &var2, &var3);

[nikomatsakis]

I opened sexxi-goose#2 with some suggested edits

[nikomatsakis]

Suggested change

	- This can subtly change the drop order of things and whether auto traits are applied to closures or not.
	- This can cause subtle changes to the timing when variables are dropped the drop order as well as to whether the closure implements auto traits like `Send`.
	- In most cases, these changes are not harmful, but the migration lint will nonetheless avoid them by inserting statements like `let _ = &x` to force an entire variable to be captured.

[nikomatsakis]

Make tests pass