Add fib, fact, and choose functions to spire.math.

The functions are:

  fib(n): The nth Fibonnaci number (the 0th is 0, the 1st is 1)
  fact(n): The nth factorial (the 0th is 0, the 1st is 1)
  choose(n, k): The binomial coefficient (n k), i.e. n!/k!(n-k)!

These three functions aren't hard to implement, but in Spire we have
an opportunity to create versions that are a bit faster (or more
resilient) than a totally naive approach.

There is still a lot of room to make these methods faster. But
for now they seem to perform well.
Fix cfor inlining bug.

This ended up being a bit subtle. Basically, the transform() method
doesn't correctly handle the following kinds of trees:

TypeTree().setOriginal($tree)

Basically, in this case transform() method doesn't recursive into the
$tree, but the $tree is actually where the important code is. We fix
this by matching TypeTree explicitly and calling transform($tree) when
$tree is not null.
add thyme dependency
Introduce expm1 and log1p to Trig[A].

These methods are needed to make generic programming safe for
floating-point values.

Right now, Complex[A]#log1p and Complex[A]#expm1 use naive
implementations for these. Arguably, if a complex number is real
(i.e. has no imaginary part) we should instead use Trig[A]#log1p
and Trig[A]#expm1.
Make type class instances serializable.
Prioritize Eq/Order to avoid ambiguous implicits.
Re-prioritize implicits to avoid ambiguity.
Merge remote-tracking branch 'upstream/master' into topic/serializable-all-the-things

Conflicts:
	core/src/main/scala/spire/optional.scala
Initial Quaternion implementation.

Basic Quaternion type. There are still some things missing:

1. Interoperability with Complex[_]
2. Type parameter (uses Double for now)
3. Needs nroot / fractional pow implementation
4. Needs polar form(s)
5. Possible signum implementation
6. Benchmarks

I haven't found other (open source) quaternion implementations to
compare this one against. Also, it would be good to have more eyes
on this, especially people who are more familiar with quaternions
than I am.
Quaternion clean-up.

This commit removes some debugging code that was left in. It also gets
us some basic interop between Complex and Quaternion around equality
(and verifies that the hashCode implementations are also in sync).

Finally it fixes some bugs in sqrt/nroot (although of course nroot is
still not completely done).
Implement nroot(k) for Quaternion.

This commit adds support for arbitrary nroot's using the quaternion's
polar form. It does meant that when we introduce a type param we're
going to need a Trig[A] instance (like Complex[A] does).
Impelemented fractional power (fpow).

Unlike Complex, fpow here only accept a Double (for now). I don't have
a handle on what a quaternion taken to a quaternion power would mean
yet, so I may hold off on that one for awhile.
added dot product and some helper functions
First pass at generifying Quaternion.

This is currently not doing any specialization, and there are still
places where we're using == instead of ===. But Quaternion is generic
and the tests are passing!
Add specialization to Quaternion[A].

This commit should complete the effort to generify Quaternion. The type
is now specialized on Float, and Double, and should correctly use ===
in all applicable cases.

The only serious issue remaining is the lack of signum.

One difference between Complex[A] and Quaternion[A] right now is that
Complex uses the faster, but less precise polar operations for both pow
and fpow. Right now, Quaternion has a precise, recursive pow
implementation which is a bit slower, but won't introduce any error.
I'm not sure whether Complex should adopt Quaternion's strategy or
vice-versa.
Added basic type class instances for Quaternion.

There are a few FIXMEs in there, some of which will be more challenging
than others to actually "fix".

Also, fixed a but in nroot.
Quaternions shouldn't have a Signed instance
Fix GCD for Complex[_] and Quaternion[_].

This just removes some unnecessary special-casing.
Standardize norm and abs for Complex[_] and Quaternion[_].
Fix for < and <= bug on ULongs where comparing large number with small
number would lead to incorrect result. For example

ULong.MaxValue < ULong(1) would give true (incorrectly)
while ULong.Max > ULong(1) would also be true (correctly)

this fix resolves this issues.