This completes instruction support for the Blink tn45 example.

Take argspec pairs directly as an argument instead of taking a
pointer to an argspec pair.

The instruction table is now beefier and has redundant data, but
this simplifies processing. This should simplify upcoming work.

Also, add a "real world" example in AVRA tests, a blink program on
a ATtiny45. Some instructions are commented out because they aren't
implemented yet, but not many.

The output of the program has been verified against AVRA's own
output.

This costs us a bit of space for now but should make things a lot
simpler down the road, especially with "alias ops" which are simple
syntactic sugar for another op.

I had written this when trying different approaches to adding BR and
I forgot to remove it.

Use IX directly for argspec rows instead of going through DE. It saves a bit
of processing. The code was this way because I initially didn't use IX at all,
so as code evolved, that DE translation stayed as an artifact.

It wasn't used much so I inlined it.

We now treat the block device as fixed-size rather than trying to grow it in response
to kernel activity.

Previously, if you tried to create 2 files in a row, only the first 1 would actually appear,
because the device only ever got larger when a byte was written immediately past the end of
the device.

Now we just let the kernel write bytes to the disk anywhere, so new files can be created even
when the previous file is not completely full.

Also, fix buffer overrun in reading filesystem image, and use a more idiomatic fgetc loop.

It wasn't used much, so I replaced its use in the kernel with direct code
and moved the routine in apps/ed, the only other place where it was used.

The order in which cfspack includes its file depend on the platform. To have
tests that reliably pass, test.cfs has to be committed in.

Also, increase STDIO_BUFSIZE to 0x40 so that those while loops work.

Also, always end the CFS chain with a stop block.

fixes #55 #56 #57

ref #80

ref #80

fixes #80

Also made Makefile actually portable.

By uploading a BASIC loop and then run it, we can reduce the serial
communication to pure content which greatly reduces the overhead and make
the process much much faster.

A little life saver if your target shell doesn't have a proper at28w.

It's no longer required to use `gmake` under OpenBSD and shell scripts
no longer require bash.

In C this time. Python/Perl code is barely terser than C for these little
tools. Why bother with interpreted?

I know, this is silly, but I'm moving tools to something a bit closer to the
system. I consider perl to be more system-like than python for a simple reason:
perl is part of the OpenBSD base system and python is not.

Also, I'm learning perl and using this as an opportunity.