native-lib-loader option instead of using narSystem.

When we have <narSystemPackage>native-lib-loader</narSystemPackage>, we copy the output to /META-INF/lib according to native-lib-loader convention.

The minimal project for testing it is https://github.com/hkmoon/nar-native-lib.

So the idea is that you build the same project on multiple platforms which will generate platform-dependent attachments for each of them.

Before that, the project should be configured to generate a NarSystem classes, though. These classes are used to load the native library. And here comes the quirk: if your project depends on the `native-lib-loader` project, the NarSystem class will make use of it.

Specifically, the `native-lib-loader` will be used to unpack and load the native libraries. This requires the platform-dependent attached artifacts to be in the class path so that the `native-lib-loader` can find the appropriate native library.

Example: if you want to make a new project, say, `fatcurve`, that has native code, you can make it a NAR project, configure `native-lib-loader` as a dependency, configure the `<narSystemPackage>` tag so that a `NarSystem` class is generated (which will use the `native-lib-loader` classes because they are available), and compile it on all the supported platforms. After that, you accumulate the `fatcurve-1.0.jar` artifact from any of these platforms, and the `.nar` files – e.g. fatcurve-1.0-i386-Windows-msvc-jni.nar` – containing the native libraries, and the `native-lib-loader-2.0.2.jar` artifact, put them all on the class path and magically everything works: the `NarSystem` class will ask the `native-lib-loader` to unpack the native library and then load it.

Now, this explanation is long, and probably still unclear, so I really appreciate your help to provide a succinct FAQ entry helping NAR users understand why they would want to add the `native-lib-loader` dependency to their projects.