implement @as builtin and fix result location semantics with regards to type coercion

[andrewrk]

This branch implements #1757. It breaks a lot of code.

It also hooks up variable declarations which have type annotations into result location:

test "example" {
    // master branch: writes result into temporary variable; copies into x.
    // this branch: semantically equivalent to the following line with `y`.
    var x: Point = makePoint(); 
    // master branch and this branch: makePoint writes result directly into y
    var y = makePoint();
}

const Point = struct { x: i32, y: i32 };

fn makePoint() Point {
    return Point { .x = 1, .y = 2};
}

And it hooks up type coercion into result location semantics:

test "example" {
    // master branch: writes result into temporary variable; copies into x.
    // this branch: semantically equivalent to the following line with `y`.
    var x = @as(Point, makePoint());
    // master branch and this branch: makePoint writes result directly into y
    var y = makePoint();
}

This makes it easier to read code, since a function call is always a function call now, and type coercion is a lot easier to spot.

It also makes the language simpler, and therefore the compiler easier to work on. Less room for bugs dealing with the ambiguity of function call syntax possibly being a function call, or type coercion.

Merge Checklist

• fix tests that regressed
• update language reference documentation

Bear with me on this change. It'll be worth it. As a consolation prize for dealing with your code breaking, this is a direct prerequisite of anonymous struct literals (#685) which I plan to do next. So after you fix all your type coercions, you'll at least get to have a hot new feature to play with soon after.

[daurnimator]

I think a better idiom would be var i: usize = 0

[andrewrk]

Agreed. They are semantically identical, therefore the shorter one is preferred.

[JesseRMeyer]

Must the type parameter to @as() be comp-time known? For variably sized stack based allocations, it seems that it must be, but if pointers are all the same size, there is an alluring reason to allow runtime-known pointer type casts from @as(), or a close relative.

For example, maybe you have a single routine that returns a pointer pointing to a vector whose length is that of the active processor.

[andrewrk]

@JesseRMeyer I don't understand what you're suggesting - sounds like a proposal for a separate issue, that could use some code examples to help clarify.