Add section to documentation on shared vs. static libraries

[citibeth]

The documentation would describe a standards/convention for packagers to follow:

1. Packages that can build more than one library type should have variants "+shared" or "+static" to choose which library types are built. At least one should be set.
2. Packages that build static libraries only should ALWAYS produce position-independent code (-fPIC) if possible. This allows them to be linked by shared libraries that depend on them.
3. If position-independent code is an option for a library, it should be controlled by a variant "+fpic"
4. Packages should always build shared libraries by default.
5. MAYBE: Spack can now interpret the meaning of +shared and +static: it can drop LD_LIBRARY_PATH and RPath support for packages being linked static.

@citibeth:
2. We standardize on variants for ALL packages that control shared /
non-shared generation:
a) These variants get implemented in the core Spack code, so the
package.py files don't have to provide variant() declarations.
b) There should be a way to set these variants by default for ALL
packages (eg: I'd set "+shared" as a general Spack configuration, and then
all packages would be built with "+shared"). If this capability is not
already in Spack, it would be provided as a follow-on to PR #120.
b) I would suggest we follow existing convention used by some packages:
"+shared" means build shared libraries, "+static" means build static
libraries.
~shared" means don't build shared libraries, etc.
c) If a package is incapable of building libraries in the ways
requested, it can silently override Spack-wide defaults. But it should
throw an error if the default was set per-package. (Eg: suppose Spack-wide
defaults are set to "+shared" and mylib/package.py can't do shared
libraries. Then I can silently just build static libraries. But if a user
asks for mylib+shared, then I need to throw an error).
d) If the user does nothing, Spack-wide defaults should be configured by
default to "+shared+static".

@mathstuf said:
I agree that it should always be spelled "+shared" and "+static" (and
not "+fpic" or "+dynamic"), but I don't know about spack providing it by
default without any mention in package.py. What does py-six+shared
even mean? What about py-numpy+static?

Also, with spack knowing about shared versus static, it means that spack
can drop LD_LIBRARY_PATH and rpath additions for packages which depend
on static libraries.

[mathstuf]

If position-independent code is an option for a library, it should be controlled by a variant "+fpic"

I don't think this should ever be an option since it makes it incompatible with all shared libraries (including things like Python modules which have to be shared).

[alalazo]

Closing in favor of #5269