VM: add support for coalescing and capture-parent-scope

[schungx]

Coalesce Support

This PR adds support for coalescing operators, such as ??, ?. and ?[...] to the VM. Previously, coalescing operators are not lowered.

New opcode

A new opcode, Op::SkipIfNotUnit is introduced. This opcode is named Skip because, unlike Jump opcodes, it does not pop the value off the stack. Instead, it only inspects the value and jumps if the value is not ().

This new opcode is necessary to implement the ?? coalescing operator.

Version is bumped

Artifact version is bumped because a new flag is written for the chaining types (Step::Index, Step::Property and `Step::Method) which makes it non backwards compatible with previous written artifacts.

Implementation

?? is implemented by the new Op::SkipIfNotUnit opcode.

?[...] and ?. are implemented by adding a new flags field to the chaining types and short-circuiting where the receiver is ().

Capture Parent Scope

Rhai has a feature that, if you put a ! in a function call, it acts sorta like a "macro" -- i.e. it appears to run in-place, being able to see all variables visible at the call site.

// A function that uses the undeclared variable 'offset', which normally should raise an error.
fn offset_value(x) {
    let local_var = 999;
    x + offset
}

let offset = 10;    // Declare local variable

let result = offset_value!(42);    // call with '!'

The result is 42 + 10 = 52 instead of an error, because Rhai takes the function call as capturing the parent's scope.

Essentially it is equivalent to:

let offset = 10;    // Declare local variable

let result = {
    let local_var = 999;
    42 + offset
};

Opcode changes

Four new _CAPTURE versions of the Op::CALL_XXX opcodes are introduced.

Implementation

The flag capture_parent_scope has always been available for Expr::FnCall. When it is set to true, call functions with the current scope instead of creating an empty new one.

[schungx]

@ImTheSquid I've reversed the re-numbering of the instructions, as well as not using any assert!.

Based on your idea, I've started working on a "capabilities" system that identified the syntax features used by an AST. Then it'll be written into the artifact instead of the feature flags. A feature not used by an artifact and not built into the client still runs fine, even if the artifact was originally written by a build that enabled such a feature.

So for example, if an artifact is written by a normal build, but loaded in a build with no_index, it still loads fine if the artifact does not use arrays at all.

Matching capabilities is fine, but we'd run into the problem of detecting corrupted bytecode, which may corrupt the capability flags, turning a required cap into not. In that case, the verifier needs to double check instructions such that they always abide by the declared capabilities.

[schungx]

@ImTheSquid while refining this, I discovered that the capture_parent_scope flag for function calls is not implemented by the VM -- it became a residual fragment.

It wasn't hard to implement, so I just added that in. Now the VM really has feature parity with the AST walker.

[ImTheSquid]

Small style nits, looking good for the most part!

[schungx]

@ImTheSquid Changed made. Pls check it for one final round.