Lit currently bundles compiled .lua files if their bytecode is smaller in size than the original source file. I propose that we change this.

Issue 1: The attempt at space saving is negligible or detrimental.

Using lit itself as an example of a bundled luvi 2.9.3 app on Windows, the resulting file sizes are:

No compilation: 4,123 KB
Partial compilation (current behavior): 4,144 KB
Full compilation: 4,148 KB

While there is sometimes a reduction in individual .lua file sizes, there is actually an overall increase in total executable size here. Presumably bytecode is being zipped with less efficiency than the source? Additionally, luvi contributes over 90% of the executable size here, so there isn't much room for space negotiation.

Issue 2: Lua compiled using one luvi version may be incompatible with other versions.

More specifically, if the version of luvi used to build lit is different from the version of luvi that lit uses to build another app, the bytecode may not be compatible if different luac versions are involved. See #252.

Precompiling to bytecode isn't inherently bad! We just aren't using it in the right way. From the luac man page:

The main advantages of precompiling chunks are: faster loading, protecting source code from accidental user changes, and off-line syntax checking. Precompiling does not imply faster execution because in Lua chunks are always compiled into bytecodes before being executed. luac simply allows those bytecodes to be saved in a file for later execution. Precompiled chunks are not necessarily smaller than the corresponding source. The main goal in precompiling is faster loading.

What this PR does is remove the logic for compiling based on file size, makes compilation and all-or-nothing procedure, and changes the default behavior to no compilation.

What this PR does NOT do is add the option to select whether files should be compiled from the CLI. I'm open for suggestions on how to handle that, or we can save that for a later change.

Fixes #252.

Happy Hacktoberfest