Rework bootstrapping compiler with runtime in build.xml

Do not pack the runtime into the compiler on the first step of bootstrap, but
rather leave it as a separate file named kotlin-runtime-internal-bootstrap.jar.

This new solution will allow compiler to use its own classes from "core", not
the ones used by the runtime it depends on
Refactor CompilerRunnerUtil

Eliminate code duplication, add NotNull, make everything private, etc
Minor style fixes in ParentLastURLClassLoader
Load compiler dependencies in a separate class loader in IDE compiler runner

To be able to invoke the intermediate compiler built on the first step of
bootstrap: in contrast to the distributed compiler, it's incompatible with the
runtime produced by itself and should instead be run with the runtime in the
classpath which was used to compile it.

Drop the non-preloader mode of running compiler, because it would require using
a special parent-last class loader with exceptions specified by ClassCondition

1
Minor, rename module to conform to naming style
Include different runtime into plugin for bootstrap build
Rename Maven library kotlin-runtime -> kotlin-builtins

Also replace accidental usages of former kotlin-runtime with kotlin-stdlib
Split loadKotlin test data into two chunks

The majority of the tests stays in "compiledKotlin", while tests that use
annotations not retained at runtime go under "compiledKotlinCompilerOnly",
which will not be used as a root for generated descriptor loading tests at
runtime with reflection (as opposed to "compiledKotlin")
Test generator: allow to exclude certain test data directories
Initial support of descriptor loading at runtime
Initial support of annotation loading at runtime

In order to locate an annotated entity, we need to implement almost the whole
Java element model (which will be used anyway for Java descriptor loading)

Nested annotations are not supported at the moment. Also the order of loaded
annotations seems to be instable
Support Java symbols in runtime descriptor loading
Delete dependency of 'serialization' on trove4j

Use HashMap of wrapped objects instead of THashMap with custom hashing strategy
Prettify code in 'reflection.jvm'

Use stdlib instead of hand-written hacks, fix some warnings and unneeded !!
Include core into kotlin-runtime.jar
Add kotlin-runtime Maven artifact

Contains kotlin-stdlib and reflection implementation for JVM
Use abstract factory for reflection objects on JVM

Introduce an abstract factory class ReflectionFactory which is responsible for creating
reflection objects (KClass, KProperty, ...). The meaningful implementation is
located in "reflection.jvm" where KClassImpl/KPropertyImpl/... are accessible
and can be instantiated. The default implementation will be used in the lite
runtime with no reflection and will return nulls / throw exceptions there.

Put all functions, calls to which are generated by JVM back-end, in one place:
the class named Reflection which contains only static methods. Previously these
functions were scattered across different files in module "reflection.jvm".

The code using reflection may now be compiled against either runtime, but
reflection features will work if and only if reflection is accessible at
runtime
Drop unneeded factory methods

Either ReflectionFactory or direct creation is now used instead