[RFC] Update to 0.15

[elpekenin]

Started looking into a PR for the update, but it will require some big and breaking changes, so i wanted to raise the issue first for discussion.

TODO list:

• Update dependencies: Sent PRs to both chameleon and smart-pointers, recover is already updated upstream
• Removal of usingnamespace. This breaks the Bitflags "hack" mixin. I can think of 2 alternatives:

// A: "wrapper" around the input type 
const Bitflags = @import("util.zig").Bitflags;
const Flags = Bitflags(packed struct {
    flag: bool
    ...
});

// creation
const f: Flags = .{ .flag = true }; // old
const f: Flags = .from(.{ .flag = true }); // new

// operations
f.contains(f); // remains as is

// reads
if (f.flag) // old
if (f.inner.flag) // new

// integrates nicely with .format and .jsonStringify

// B: namespace providing operations
const operations = @import("util.zig").Bitflags; // renamed import for readability
const Flags = packed struct {
    flag: bool
    ...
};

// creation
const f: Flags = .{ .flag = true }; // remains as is

// operations
f.contains(f); // old
operations(Flags).contains(a, b); // new

// reads
if (f.flag) // remains as is

// extra work for .format and .jsonStringify
const T = struct {
    ...
    const ops = operations(@This());
	const format = ops.format;
    const jsonStringify = ops.jsonStringify;
};

• Changes to Node types
  • Index is now a different type (enum (usize) { _ }), there's also OptionalIndex. Most places just need a call to @intFromEnum, others would need some triaging (eg: avoiding the @compileError inside Walker.pushFullNode, because index no longer falls into the u32 branch)
  • Data isn't struct { lhs: Index, rhs: Index } anymore, it is an untagged union, where the variant to be read is defined by checking the node's tag. This is likely the biggest change. Would probably involve:
    • Removing NodeDataKind and instead handle each specific Node.Tag on a big switch
    • Adding something like get{L,R}hs(node: Node) Node to ast_utils.zig to access the relevant nodes on each rule's code
• Writergate and ArrayList(now unmanaged): These take a little work but easily doable

[DonIsaac]

This migration is turning out to be very far from trivial. The zig team re-wrote the parser + ast node structure (for the better), but this forces us to make major changes to most of the source code. I'm splitting this into pieces, and copying over the old node/parser/ast/etc into the codebase.

This may end up being more than a migration tactic; it could be nice to support linting code still using 0.14.1. I'm not sure if this is desirable, I'll need to ask around.