Order of well-definedness checks unexpected

[gauravpartha]

There are various cases where Carbon does well-definedness checks in an unexpected order. Some of these issues have been fixed in #429, but there are still some issues left. This is not a soundness issue, but an "error reporting" issue.

In particular, there are various cases where Carbon checks the well-definedness of a parent node before checking the well-definedness of a subnode. Currently, the reason for this (sometimes unexpected) order seems to be because certain parts of the implementation rely on this order (e.g., due to manipulation of mutable state).

Unexpected examples include:

• Field accesses: Carbon checks whether there is permission to e.f before checking whether e is well-defined.
• P(e): Carbon checks whether there is permission to P(e) before checking whether e is well-defined.

[gauravpartha]

The order for field access was fixed in #451.