Added `nil`

Will need this after all, since `null` and `undefined` are
perfectly legit values in for instance sequences. A case could
be made that at least `null` should have the semantics of
`nil`, but I think it has too much baggage and is used for too
many other things.

I reckon `nil` is a clean slate.
Added `once` for one off memoization

This is mostly useful for parameterless getter style functions
where subsequent return values will be the same. This'll be
useful in `seq` where `next` yields a new sequence on the
first call, but returns the same instance on subsequent calls.
Made `isNil` return true for `nil` as well

Now that `nil` exists, should this function really return true
for `null` and `undefined`? Me thinks yes, because it's pretty
intuitive, but I'm not sure.
Refactored `seq` to make it trivial to create lazy sequences

If the `seq` constructor is called with just the one thing, we
assume like before that it's an object that is sequencable.
If we get more parameters however, we assume the sequence is
lazy and the first parameter is the initial `head` value, the
second is a function that returns the next value, and the
third is an optional size.

This change *should* also enable `seq` to be compatible with
generators, although I haven't tried it yet. All in due time.
Added lazy `range`
Use `String` constructor instead of concatenation trick

The concatenation trick will call `valueOf` under the hood,
which has funky implications if you're dealing with `seq`
since we're overriding `valueOf` there.
Changed `type` to return prototype name if available
Added `vec` as a way to realize seqs into arrays
Change `seq` to deal with `nil` instead of `null`
Added `take` as a lazy sequence
Added `isEmpty` and changed `count` to throw on uncountables

Previously `count` would return 0 for falsy values, but this
doesn't really make much sense for booleans, for instance.
Now, it'll throw if the object is uncountable.

`isEmpty` will return true for anything that can be counted,
and since it uses `count` will throw if something can't.
For seqs, it'll only return true if `length` is reported as 0;
undefined lengths are returned as `false` because we can't
know.
Added the `constantly` function
Changed name of function returned from `constantly`
Changed `count` so it never tries to count sequences

Counting lazy sequences makes little sense, since it requires
that the sequence is realized. It's just going to waste CPU
cycles and isn't even guaranteed to work. So for sequences
we'll just return `length` and if a lazy sequence doesn't
supply it we'll just return `undefined`.
Refactored `seq` again; also added the `lim` function

The signature of `seq` is now much less smelly. The `length`
field is still around, for those lazy sequences that *do* know
their length up front (range, for instance.)

The `lim` function was added as an abstraction to the common
case of having functions that should only be callable a set
number of times. This makes it very easy (and safe!) to
implement bounded sequences, by simply limiting the number of
times the `next` function can be called. This is also used
within `seq` to limit calls to `next` in those cases that a
length is specified and the collection is lazy.

A `seq` can be lazy, not report a length, and *still* be
bounded; as is shown by `take` which doesn't report its length
even though it possibly could. This is because while it's true
that `take` has an upper bound of `n`, it may actually be less
than that in case the underlying sequence has fewer items.
I figured the principle of least surprise dictates in this
case that `take` should simply have an undefined length.
Added an implementation of the iterator protocol for `seq`

Because of how ES6 iterators work, in order to support the
`for..of` syntax sugar nicely we have to implement the `next`
method on the `seq` object itself. This method has side
effects, but I figure it's a small price to pay for syntactic
sugar.

An argument can (rightly) be made that these small prices we
pay for having nice things eventually turn into balls of mud,
which is why we can't have nice things. Maybe that's so, and
maybe it'd be better to implement `next` in a separate
function or as the result of an iterator property on `seq`.
([See discussion][it].)

That said, syntactic smells are also smells, and I reckon the
only winning move in this game is not to play. Since that's
too late I figure what the heck – let's do this.

As to the perhaps odd implementation of `next`, where the
iterator rewinds itself after running a course, is such that
`seq` objects can be used in multiple `for..of` statements.
For more on that, please refer to a [discussion I started on
es-discuss][es-discuss] and the [bug] that was filed as a
result.

[it]: https://github.com/mstade/funkis/pull/4#issuecomment-39681094
[es-discuss]: https://mail.mozilla.org/pipermail/es-discuss/2014-April/036874.html
[bug]: https://bugs.ecmascript.org/show_bug.cgi?id=2606
Renamed `seq.head` to `seq.first` and `seq.tail` to `seq.rest`

This naming is so much nicer, it's sugar and spicer.
Added tests for ES6 iterator protocol on seq
Merge pull request #4 from mstade/lazy-seq

I feel reasonably good about this now, so I'm going to merge it. There will surely be other things added later, but as a first approach I reckon this is alright.