[documentation,release] Make the UMFPack class appear in the doxygen even when not configured with UMFPack

The user should see from the documentation that he/she could use UMFPack,
provided the missing external dependency is installed.

Add missing underscore in PTHREAD_CFLAGS.
Add missing returns in solver functions.

- don't try to copy an incomplete matrix when passing it to rowWiseBuild
- test copy assignment in addition to copy construction
- make sure preallocated matrix can hold all inserted data

Previously, the tests supposed to fail would not have been
detected with -DNDEBUG. With this patch we use cerr to report problems
and return a nonzero error code on completion.

Previously there seemed to be a copy and paste mistake and bcrsimplicitebuiltest
used the same source file as bcrsbuildtest. This patch fixes this.

After the recent changes to BCRSMatrix, row and column sizes are now only
set by allocate() because several places assume a correlation between
the set number and rows and the allocation state. Thus the copy
constructor and the assignment operator don't directly copy those values
over, but initialize them to 0. The correct values are then set by
allocate. The row-wise build mode is a special case that requires
iterating over the source matrix rows before allocating memory.
Unfortunately, the copy constructor tried to use the (0-initialized) row
count of itself as iteration bound instead of the source matrix's one.

Fixed by doing the same thing as the assignment operator: Just use the
number from the source matrix.

Fixes FS #1394.

This reverts commit 5d8e6db1.

While the patch above fixes the issue in FS #1394, it creates an
inconsistency between the way the copy constructor and the assignment
operator work.

Reverted before applying a more consistent fix.

Due to the latest changes the number of rows was not copied correctly
in all cases.This patch introduces the old behaviour.
Should fix FS #1394.

This more easily triggers FS #1394

- Don't do anything if we're in build stage notAllocated
- Reset pointers to nullptr after deallocating
- check whether rows have been allocated before accessing them

[BCRSMatrix] Prevent changing the implicit build mode parameters after matrix construction has started

Valgrind was complaining about using unitialized values in some places...

notbuilt) and building

Right now, some build modes reuse the same build stage value across
several actual stages. This patch splits the notbuilt stage into
notAllocated and building, avoiding that ambiguity.

- Introduce new exception BCRSMatrixError and use it throughout
  BCRSMatrix
- Introduce new exception ImplicitModeOverflowExhausted, which is thrown
  by compress() for the implicit build mode. Also improve the error
  message for that exception to really help the user understand the
  problem signalled by this exception and how to remedy the situation.

This patch adds checks to make sure the user has actually set valid
parameters before trying to allocate the matrix in implicit mode.
We use a negative value for the overflow fraction as an indicator for
this.

As part of the cleanup, this patch also makes sure that avg and
overflowsize are always initialized to a well-defined value.

This was obviously never tested - don't try to assign the overflow
fraction to the map holding the overflow entries...

We iterate over all rows anyway, so avoid the additional loop.

compress() uses iterators that are off to enable a *(++it) = ... idiom,
which already confuses me right now. That confusion will only be worse
when I look at the code again in half a year, so let's clean that up
right now.

ImplicitMatrixBuilder now has some more documentation and a second
constructor that takes all required arguments for setting up a matrix in
implicit build mode. So you can now create an ImplicitMatrixBuilder
directly on top of a default-constructed BCRSMatrix.

- Don't needlessly specialize the wrapper, we can still do that
  we we encounter the need for it.
- Add some doxygen documentation.
- Clean up formatting.

This one slipped through the cracks when renaming the build mode...

OS X does not support feenableexcept(), so don't try to call it.
Enabling FP exceptions wouldn't really help anyway because that only
works for the FPU, but all floating point operations on 64-bit OS X
are done using SSE / AVX, which does not support FP exceptions.