Use a synchronizedMap for typeOptions and libraries instead of seperate lock
Use a synchronizedMap for typeOptions and libraries instead of seperate lock

The currently used lock is to broad and can cause a deadlock when
loadLibrary is called from different threads, that need
recursive initialization of dependend classes.

The codepaths that hold the libraries lock to prevent duplicate
execution of initialization code. The lock can be dropped in favor
of a Collections#synchronizedMap construct, that only protects the
Map structure.

In detail:

- loadLibraryInstance: The lock on libraries prevents a duplicate put of
  WeakReference to the static singleton instance of the library.
  This is uncritical, as the References are equal from the outside view.

  The library won't be initialized twice, as the JLS defines, that
  class initialization must happend under a lock.

  The codepath can be entered multiple times without negative consequences.

- findEnclosingLibrary: The lock on libraries prevents recursive calls
  to Native#findEnclosingLibrary and CallbackReference#findCallbackClass.

  These paths have no side effects apart from caching, so can be
  entered multiple times.

- getLibraryOptions: The lock on libraries prevents building the library
  options map multiple times. As there are no side effects, locking is
  not necessary.

- cacheOptions: The lock on libraries prevents multiple puts of the
  options map into the typeOptions and libraries maps.
  As there are no side effects, locking is not necessary.

trejkaz/jna,trejkaz/jna,trejkaz/jna,trejkaz/jna,trejkaz/jna,trejkaz/jna