get rid of end1/end2 prims (they are variables!!!)

this is rather amusing.  end1 and end2 are link variables, so they
don't need to also exist as primitives... but they did, and for years
nobody noticed. wtf.

the change shouldn't be visible to users... I don't think. maybe
some error messages might be a little different, something like that?

what finally uncovered the change was my changes to when TokenMapper
runs; instead of the prims shadowing the variables like before,
my changes inadvertently made it so the variables shadowed the prims.

if you look at the Team.txt diffs you'll see that this change causes
us to generate worse code for end1 and end2, because we lose the knowledge
that the end1 and end2 variables always hold turtles, never any other type.
this would be rectifiable by adding an optimization called
"_linkvariableagent" similar to "_turtlevariabledouble", but I don't
think it's important enough to bother with.

note that I don't think it would work to make end1 and end2 be prims
only, or at least, doing so would probably require tearing up a bunch
of code.  it's by analogy with who for turtles and pxcor and pycor for
patches; if those are variables, so must end1 and end2 be.  if we got
rid of the variables I would expect breakage in import/export-world
and perhaps elsewhere.
delay instantiation of Instructions until IdentifierParser

this makes waaaaaaay more sense than having it happen during
lexing. been wanting to make this change for yeeeeeeears.

this is part of my ongoing project of reducing compiler front end
dependencies on engine code.