Reduce mem/time for boot and tighten up sizes

Rebol's native function specifications ship in the binary, and as they are textual they are compressed with the DEFLATE algorithm from ZLIB.

When trying to run Rebol under VC2010 Express, this decompression of this boot code would crash a good bit of the time (but work sometimes(?)).  I began to tighten up the boot code to get a handle on what was going on.

The compressed data was munged with a cryptographically weak scrambler called [Cloak() a.k.a. encloak](https://github.com/rebol/rebol/blob/4d9840f8e661e7067472e828ee6ad8dd3008b247/src/core/s-ops.c#L296).  Scrambling the compressed textual representation of the Rebol natives represents no advantage I can imagine.  It just means a roughly 50K buffer is copied and churned on every boot...rather than just using the constant array as-is.  So I removed that.

I also removed some unused options.  NON_ENCODED_BOOT which did not have corresponding code in %make-boot.r.  There was also an unused ->script field of Boot_Block.  Added a precise double check and got rid of the arbitrary boot decompression limit of "200000".  Also...if had to make a wild guess about the question posed by Carl in u-compress.c:

    output = Make_Binary(size + 20); // (Why 20 extra? -CS)

...I'd think it was related to the 20 byte length of the checksum/secure of "REBOL Version 3.0".  Perhaps something to do with the cloaking algorithm at some point in time--expecting the buffer to have at least the cloaking key length of extra space at the end?  It certainly seems arbitrary, and not seeing any other 20s I decided to axe it.

At first this seemed to solve the MSVC build crash, though I didn't know why.  But I've seen it crash again since.  So there's something else going on, though this did seem to make it less frequent, but it could have to do with incremental linking.