Rename `env.build` to `env.optimize`

[ArmorDarks]

An attempt to clarify the terms.

Currently, under the term build we mean "optimized build". It worked and seemed right, because when we run grunt build we on purpose invoke a specific, wider set of tasks, to get better-optimized build. And thus, we used env.build as a reference, which denoted that system right now in the optimization state (build-one) and should treat assets according to it.

env.build, most specifically, affects the size of the produced files and filenames (include or not include .min part). And thus, it affects file paths in templates and scripts.

However, as Kotsu evolved, it started to make less sense since some parts of that system are quite independent. For instance, Webpack optimizations can be triggered by its own, not within grunt build task. And that sometimes makes perfect sense.

Besides, env.build, which expressed an optimized state of the system, became a quite confusing term. It makes sense when you read the explanation above, but doesn't in isolation. For instance, while looking into Webpack config you see env.build variable. What exactly it means? Like, really nothing.

This also leads to a terminology confusion. We mean that build is "optimized build". However, npm start in fact produces build too, but that's not the build we meant originally. And you can even do npm start -- --optimized which makes sense during testing. But that produces another build, but not the build we meant!

So, it feels logical to provide more self-describing variable env.optimized and deattach build command from the original meaning of the "optimized build".

There are few concerns, though:

1. grunt build --optimize or grunt build --optimizED?

2. We still have that command grunt build which triggers part of the optimizations. That means that you can run npm start -- --optimize to get partially optimized development build with watch or npm run build (`grunt build --optimize) to get fully optimized build without watch.

   I'm trying to get is it correct, since it feels like not that obvious.

   Maybe the problem is in the intention we try to convey here. For instance, what difference we really want between npm start and npm run build is watching. So, when I run npm start I expect it to be build and watch, while npm run build should not. In that case, we'd want the additional command to run optimized build. Or maybe the list of commands should be completely revisited. Still thinking about it.