Using _vectors_ as fundamental datatype could make for a really neat experience.

Imagine e.g.:

* fundamental arithmetic operations that apply to both vectors and scalars
* implicit component-wise or vector-wise operations
* scalar values as 1D vectors
* higher order functions to manipulate those vectors
    * `map` function that applies a (quoted?) word to all vector elements and returns the result
    * efficient parallel operations
* a rich library of vector manipulation functions
* or even: matrices as a fundamental datatype?
    * problem: probably harder to conveniently enter via a 1-D repl
* sound more and more like a RPN version of APL…

Back to reality, here is what this prototype actually adds:

* new `DList!int` based datatype alongside the existing int, string and bool types
* basic support for printing such values in a readable fashion
* new fundamental `:` word that constructs a vector of two elements
    * `1 2 :` yields `[1, 2]`
* adapted `+` and `*` to support component-wise operations
    * `1 2 : 3 +` yields `[4, 5]`

Use `nixpkgs-unstable` by default as `dub` currently fails to compile somewhere inside its testcases.

Due to the non-trivial way tokens were previously processed the compiler could not safely perform tail-call elimination. Thus the _slang_ evaluation depth was restricted by the maximum call stack size.

This issue is mitigated by introducing deferred word resolution - i.e. pushing expanded tokens onto a buffer stack and processing them in an explicit loop.

This change ties into the implementation of the language's conditional primitive. The previous implementation did implicitly not support direct nesting of conditional expressions such as:

	truthA if
		mainBranch
		truthB if
			secondaryMainBranch
		then else
	then
		alternativeBranch
	else

This issue is now made explicit by disallowing direct nesting of conditionals as depicted above. Appropriate exceptions are generated when required and the conditional primitive is reimplemented in a more robust fashion under the assumption that this rule holds. Note that nesting is still fully supported iff. the nested conditional is contained in a deferredly evaluated word. As a positive side effect this will make it slightly harder to generate unreadable code by forcing developers to write simpler words.

The main change of the conditional primitive lies in deferring branch token processing until the conditional expression is concluded by `else`. This is achieved by capturing non-dropped tokens in an internal buffer akin to how the word definition operator `§` is implemented.
The branch buffer is discharged after `else` is evaluated. Discharging is triggered via the newly introduced `result` method of the primitive evaluation module. This avenue for injecting tokens into the processing stream may be used by further primitives in the future.

i.e. `1 if true then false else` evaluates to `true`, `0 if true then
false else` evaluates to `false`.