Added Fexl functions bad, cons, cos, log, null, rand, seed_rand, sin.

I completely eliminated the "once" function, which turns out to be utterly
unworkable.  The way combinators fold into each other, you don't ever have a
definite "handle" on a memory value that can be modified in place.  I fought
with this for a while before coming to that conclusion.  It's just as well.
The use I had in mind for "once" is much better served with simpler, ordinary
techniques that don't rely on magic in-line replacement of a value.

As an example, see the new random number tests in test/a1.fxl.  There I create
list_rand, which is an infinite list of pseudo-random numbers.  I can grab the
first 5 of those with the normal "first" function, and the resulting list of
5 numbers remains stable and repeatable.  No need for "once".

Same goes for test/stats.fxl, which extends the technique even further, where I
create list_rand_ror as an infinite list of normally distributed random rates
of return with mean 1.4 and standard deviation 6.0.  Again, no need for "once"
at all.  So away it goes, a completely unnecessary non-concept.

Now, let's discuss the new "rand" and "seed_rand" functions.  If you look in
type_rand.c, you'll see that I just call the built-in rand() function to get a
random integer, then divide that by RAND_MAX to get a random double in the
range 0 <= x <= 1.

Because I'm dividing rand() by RAND_MAX, it made sense also to divide the seed
passed to srand() by RAND_MAX.

Now you might wonder why I didn't just provide a direct interface to the raw
rand() and srand() functions which use integer values only.  The main reasons
are:

  1. I really don't have much use for random integers in the range 0 through
  RAND_MAX.  In my statistical applications, I much prefer the range [0,1].
  So I might was well divide by RAND_MAX straightaway and be done with it.

  2. If I had not divided all the results by RAND_MAX, then I would have had
  to provide a "RAND_MAX" function to retrieve the value of RAND_MAX inside
  Fexl, so I could do the division there.  Ugh, no thank you.

Note that I have some very specific reproducible test cases in test/a1.fxl.
Those depend on the rand() and srand() functions being portable across a
variety of machines.  I've tested in on 5 different machines, and it's portable
across those anyway.  If I ever encounter a machine where the stream of numbers
is not reproducible from a given specific seed, then I would have to reverse
engineer libgcc's algorithm and code it explicitly to give the same results on
that machine.  I really, really, *need* reproducible random numbers that are
portable everywhere.

Changing subject, the cons and null functions are the standard list
constructors, which I've gone ahead and implemented in C.  These are equivalent
to:

	\null=(\null\cons null)
	\cons=(\x\y \null\cons cons x y)

I made a change to type_later, where I now set f->T to type_A instead of
type_I.  That's needed to avoid creating a form ((I x) y) which itself has
type_I, and thus erroneously reduces to y.  By forcing type_A, it reduces
properly to (x y).  There's a test for this in test/a1.fxl.

I also changed a few "TODO" comments to "LATER".  I'm reserving "TODO" for
things that must be done before the next commit.  That way I can run ".todo"
and if it's clean, I'm ready to go.  To uncover the next layer of priorities,
I can run ".later" and change a few LATERs to TODOs again.