Update to 0.3.8

CHANGELOG:
0.3.8
-----
* Performance tweaks
* bytestring-in-base flag default to False
Updated devel/hs-utf8-string to 0.3.8
Import parsec-3.1.5 as textproc/hs-parsec,
packaged for wip by pho.

Parsec is designed from scratch as an industrial-strength parser
library. It is simple, safe, well documented (on the package
homepage), has extensive libraries and good error messages, and is
also fast. It is defined as a monad transformer that can be stacked on
arbitrary monads, and it is also parametric in the input stream type.
Added textproc/hs-parsec version 3.1.5
+ hs-parsec
Import data-default-instances-base-0.0.1 as
devel/hs-data-default-instances-base,
packaged for wip.

Default instances for types in base
Added devel/hs-data-default-instances-base version 0.0.1
Import data-default-instances-containers-0.0.1 as
devel/hs-data-default-instances-containers,
packaged for wip.

Default instances for types in containers
Added devel/hs-data-default-instances-containers version 0.0.1
Import data-default-instances-dlist-0.0.1 as
devel/hs-data-default-instances-dlist,
packaged for wip.

Default instances for types in dlist
Added devel/hs-data-default-instances-dlist version 0.0.1
Import data-default-instances-old-locale-0.0.1 as
devel/hs-data-default-instances-old-locale,
pkgaged for wip.

Default instances for types in old-locale
Added devel/hs-data-default-instances-old-locale version 0.0.1
+ hs-data-default-instances-base, hs-data-default-instances-containers,
  hs-data-default-instances-dlist, hs-data-default-instances-old-locale
The package uses the "python" executable for building the python bits.  If it
isn't present in the package build sandpit it may reach out and use a possibly
unmanaged version of python.  On Linux that might be some base system copy of
python, which would only be the same version by chance.

If it happens to be, say, python 2.6 - but Pkgsrc is defaulting to python 2.7,
then the installed files will have the wrong filenames, the PLIST won't match,
and the build will fail (not to mention that the built files may well be
incompatible with the intended python anyway).

Having the "python" tool in the sandpit solves this problem.
Fix issues on Darwin

Makefile:
  See ${WRKSRC}/libgcc/config/t-slibgcc-darwin: It uses strip(1) to
  create a stub library, not just to remove symbols, so we must not
  let strip(1) be a no-op regardless of ${INSTALL_UNSTRIPPED} or the
  build fails for missing files.

patches/patch-libgcc_config_t-slibgcc-darwin:
  If we don't install libgcc_s.10.[45].dylib, our gcc links binaries
  with *both* /usr/lib/libgcc_s.1.dylib and
  ${GCC_PREFIX}/lib/libgcc_s.1.dylib, which is certainly a bad thing.

patches/patch-libjava_Makefile.in:
  Tell libtool the fact that libjvm.so is a module to be opened with
  dlopen(3). This is actually needed on Mach-O systems like Darwin.