Neg impl for vec4.
Macro-abstracted Increment and Decrement impls.

Added swizzle tests and some missing impls.
Add bench target for test driver.
Added ivec4 increment tests.  Added first benchmark test.
Fixed test binary makefile rule to depend on Makefile itself (to catch changes in flags).
Some revisions to make makefile clearer.

Not sure if either of these changes are actually necessary.  In
particular setting RUST_TEST_TASKS=1 for benchmarking may be
unnecessary depending on what test lib considers "sane" defaults for
benchmarking.
Added SoA benchmark, completing port of core_type_vec4 tests.
Remove dead commented-out code.
Macro-abstracted Neg and DotProduct impls.

Removed dead pre/post-inc/dec-rement code.
Added `vec{1,2,3,4}!` macros.

`vec{1,2,3,4}!` macros allow trading `vecK!(...)` for `vecK((...))` in
overloaded ctor pattern.
Migrate double-dispatch trait definition macro to common lib root.
Generalized double_dispatching macro to abstract over return type as well.
Factored scalar value traits+impls to separate mod.
moved various "newish" operator traits to separate mod.
Added EspilonEq trait for fuzzy comparisons with varying epsilon.

Pub-ified the members of the vecs so that I can construct them from
scratch for parametric `T`.
First bit of matrix test porting.
Finished remainder of core_type_mat2x2 tests.
Tests and impl for mat2x3.

Now is time to think hard about macro-abstracting the combinatorial
impl patterns I am seeing.
Used my new `all_choices` macro to auto-gen combinatorial impl explosion.

The Rust macro system has some rough corners.  I am not thrilled with
the treatment of comma (and/or lack of expressiveness regarding when
commas are required and are optional).  I *think* that an oddity
related to this is what led me to adopt the hack of always putting an
ignored base case on my constructed list of identifiers: while I could
go from `(z)` to `(y,z)` and `(x,y,z)`, I could not go from `()` to
`(z,)` nor `(z)`.

----

Also did some other macro-hacking to ease the generation of the `row`
and `col` methods for the various dimension-specialized matrix
implementations.  However some weaknesses in the macro system led me
to take a side-track hack and break my desired `Matrix` trait up into
two traits: `Columns` and `Rows`, basically to divide and conquer the
effort of generating method code for the `col` and `row` accessors
which tend to be very uniform in one of the two dimensions (i.e. "row"
or "col") and somewhat non-uniform in the other dimension.  It may be
feasible to actually auto-generate the whole method impl by building
up the fields for the struct construction expression incrementally,
but since I only have to deal with the three cases of {2, 3, and 4},
hard-coding the implementations (apart from parameterizing over the
magnitude of the opposite dimension) seemed easier.

I did have to resort to using the type `tt` for the input to the
driver macro `impl_ColRow_for`, since apparently the macro system does
not like to first type something as `$expr` and then later try to pass
it into a macro expecting a more-specific input like `2`.  An
interesting detail and I think a sane one, but something to be aware
of when developing macros.
Added ports of core_type_mat2x4.

I am narrowing in on the effective patterns here, such as making a
macro invocation for a 2*4 case generate impls for both the 8-tuple
and the various pairs of 4-tuples, or 4-tuples nested inside a 5-tuple
of scalars, etc.