Major improvement in the propagation of type_open in parse.c.

Recall that type_open was designed to indicate that a form contained symbols,
i.e. it was not a closed form.  That allows the lambda abstraction routine to
avoid descending into closed forms, needlessly looking for symbols which of
course are not there.

To propagate the type_open, I would call an "apply" routine to apply two forms
together.  The correct rule is that if *either* of the two forms is open, then
the result of applying them together is also open.

Unfortunately, I've had a long-standing bug in the apply routine, which said
that if *both* of the forms were open, the result was also open.  This would
fail to mark many forms as open.  Consequently we could have forms that contain
symbols which were *not* marked as open.

Ordinarily that would manifest as a fatal error, and nothing would work at all.
However, when I first unconsciously introduced this bug, who knows how long
ago, I also put in a "work around" in the get_pattern routine, which said in
effect go ahead and punch into *all* applicative forms, *regardless* of whether
they're marked as open or not.

That certainly worked around what would ordinarily be a fatal error, but it
also pretty much negated all the efficiency gains of using type open in the
first place!

In this new version I've resolved the issue entirely, and I now propagate
type_open correctly.  The result is that the a3.fxl test, which deliberately
mentions every symbol defined in the standard environment, now runs in 0.04s
instead of 0.11s -- i.e. it's nearly 3 times faster.

That's not a lot of absolute clock time, but there's a larger issue here, apart
from just having clean and correct code.  I discovered this error while I was
in the process of removing the "symbol stacks" from parse.c., i.e. inner_syms
and outer_syms.  The idea is that at the end of the parse, instead of relying
on outer_syms to tell me what symbols the form contains, I can just look in the
form itself, grabbing the first symbol in left to right order, abstracting that
symbol out, applying that form to the definition of the symbol, and then
repeating until there are no more symbols.  That's actually screaming fast,
especially when type_open is propagated correctly.

Well, my initial attempts were not working at all because I was relying on the
accuracy of type_open.  I quickly discovered the problem, which led to the
revision you see here.  Now I can once again resume work on removing the symbol
stacks.

Moreover, I have a much larger goal in mind.  Instead of using lambda pattern
substitution, I plan to go back to using combinators.  I was using combinators
long ago, but I found that lambda substitution was much faster.  But now I'm
pretty sure that's only because I was using combinators which behaved in an
ordinary way, meaning that they had to churn their way through the evaluation
process one step at a time.  For example, (S x y z) became ((x z) (y z)), and
then x would absorb its argument z as another combinatorial reduction, and the
churning would continue from there.  It all worked of course, but it was slow
in comparison with the pattern substitution I currently use.

Now I realize that I can do combinators which behave far more aggressively, if
I switch to using reduction routines which look like this (in the C code):

	value z = x->T(x,y);

That's how we'll do aggressive function application.  We'll use A(x,y) for lazy
function application, which is still necessary in cases such as the right side
of the S combinator rule.  The S combinator should look like roughly like this:

	value left = x->T(x,z);
	return left->T(left,A(y,z));

Of course, I could define a function app(x,y) as a shorthand for x->T(x,y), and
the C compiler is very good at inlining such definitions.  In that case the S
combinator could look like this:

	return app(app(x,z),A(y,z));

Note the aggressive form on the left side, and the lazy form on the right side.

This commit message has reached epic proportions, but this is basically how I
"blog" these days.  I'm getting back to work now.  Talk to you soon!