Library resolving

A big problem with writing library wrappers with alien is that you have to hardcode the shared library names. For example the readline wrapper reads:
    
     `{ [ os unix?  ] [ "libreadline.so" ] }`

Which doesn't work on most Linux systems which use versioned sonames. On my system (Ubuntu 12.04), the soname is `libreadline.so.6` but the 6 could be something else on other Linux distros. Most of the wrappers fails in the same way.

So what is needed is an abstraction on top which figures out the correct library name automagically which is what this pr implements. So the add-library declaration for readline would, using this vocab, read:

    << "readline" "readline" find-library cdecl add-library >>

The `find-library` word works similar to the find_library function in Python's ctypes package: http://docs.python.org/2/library/ctypes.html#finding-shared-libraries

On Linux, /sbin/ldconfig is used to find the right lib. On Windows, Factor's installation directory and a directory called `dlls` inside of it is searched to find the correct dll. On OS X, find-library is more or less a noop. `"readline" find-library` always return `"libreadline.dylib"` because I don't know what library resolving is appropriate on that platform.

The dlls directory is searched because it looks much better to have all dlls in a separate subdirectory than in the root installation directory as you otherwise would place all dll files as Windows doesn't have globally installed libraries like unix does. In my other pr, waf-build-system, the msi installer creates the dlls directory and populates it with all files from http://downloads.factorcode.org/dlls/

Because the pr only adds a vocab I don't think it should cause any problems. Wrapper vocabs can one-by-one be upgraded to use the find-library word.