[native-image] Support for `@argfile` CLI option

[lazar-mitrovic]

As seen in issues #2995 and graalvm/native-build-tools#85, (mostly Windows) users are facing with issues when their native-image CLI invocation exceeds maximum allowed length. This is mostly due to large classpaths with long/absolute addresses.

In Windows this originates from a documented Windows limitation.

There are several possible workarounds that are commonly used for java/javac invocations:

• Shortening paths by using relative addresses and/or by moving dependencies to a known short path - C:\\TMP for example
• Using fat jars. This is approach that we are currently pursuing for native-build-tools as a stopgap solution for the 0.9.4 release.
• Setting Classpath using a bootstrap jar with a custom manifest that contains the entire classpath. This is approach that we explored first, but it proved ineffective, since @melix discovered that the Native Image driver would extract the classpath from said jar and invoke the image builder through CLI (thus resulting in same error message).
• Using @argfile option. This option was introduced to javac executable in JDK7 and to the java executable in JDK9, and it is the recommended way to pass long CLI invocations. ATM we don't support this option.

Last two points are of importance for this proposal. In order to fully resolve this issue we must ensure that:

• Driver passes the command line options to the image builder using argument file instead of CLI.
• We expose the @argfile configuration option to the end user through native-image tool.
• Ensure that parameter parsing works the same way - --verbose should have the same output when invoked using @optionFile as when invoked using a standard CLI.