compiler: shorten the name of inferred error unions

[nektro]

consider the following Zig code:

const std = @import("std");

pub fn main() !void {
    var x = foo("hello");
    x.len -= 1;

    std.debug.print("{d}\n", .{x});
}

fn foo(a: []const u8) ![]const u8 {
    return a;
}

under status quo you might get an error like so:

test2.zig:5:6: error: error union type '@typeInfo(@typeInfo(@TypeOf(test2.foo)).Fn.return_type.?).ErrorUnion.error_set![]const u8' does not support field access
    x.len -= 1;
    ~^~~~
test2.zig:5:6: note: consider using 'try', 'catch', or 'if'

this, while technically accurate, is extremely verbose and not practically useful in most cases (it doesnt even fit in the default width of the github view!). many advanced users see it as noise and beginners get overwhelmed while they are still grasping Zig's error system. alternatively, this patch reduces it to the following.

test2.zig:5:6: error: error union type '![]const u8' does not support field access
    x.len -= 1;
    ~^~~~
test2.zig:5:6: note: consider using 'try', 'catch', or 'if'

now the "error union type does not support field access" text is much more accessible and the ! is retained to match the return types users see in functions that produce this message.

additionally added a test to ensure error messages with functions that have an explicit error set are retained.

further work would add a note where x in this example is defined but i decided to save that for a subsequent pr.

[mlugg]

The idea of this isn't terrible (although I don't personally agree with it), but the implementation is fundamentally flawed. This could result in nonsensical errors like expected type '!void', found '!void' and expected type '', found 'u32'.

[VisenDev]

I would support something to this effect as user friendly error messages are very helpful, especially for beginners. One of the things rust gets so much applause for are its user friendly error messages. I would love to see zig going down this user friendly path more

[silversquirl]

I like this idea in concept but I think it needs more discussion and should be a proposal.