Runtime diet caching

[schveiguy]

Looking at the way diet parses and processes files, I firmly believe that the cached version is the better version. First off, it's going to use WAY less CTFE, because it simply imports the result. This means both less time and less memory, something which my vibe.d app is straining against currently.

But there is a large problem -- the current model must compile ONCE without any caching for this to work. Essentially, it compiles the file at compile-time, then at runtime, writes the cached result into a specially named file, and then you have to compile again to get a benefit. But this is really a build step, made very awkward by requiring a run of the application once. Not only that, but if you are running against a memory limit, you can't get the faster/less memory build, because you need to build once without it.

With the changes I have in #70, the facilities would be available to do this at runtime BEFORE compilation. In fact, I created a very small utility which does just this. I'm shocked at how quickly this runs and it works perfectly (parses and caches all my 31 diet files in 0.25 seconds). It cuts my compile time from about 38 seconds down to 11 seconds WITHOUT having to run 38 seconds once. If I'm reading my max memory stat correctly (though I'm not 100% sure how /usr/bin/time works), it's using 1GB less memory as well (about 30%). Finally, if we move to this type of compilation mode, there is no need to infiltrate the final executable with build steps.

The code is simple, see here: https://github.com/schveiguy/dietpc. All that remains is to try and make it insertable as a dub step.

[schveiguy]

Note also -- this depends on the cache system. If we trust the precompiler to build the file, there is not even a need to load the diet files and process the hash computation, saving even more time/memory. We could name the files filename_precompiled.d and ignore the hashing.