First GPU support (#77)

This PR is part of the gpu feature merge. The GPU implementation is not implemented here. Instead, we focus on refactoring of the original "multicore" back end so that it is ready for adding the GPU back end.

This is a big and messy change, for which I am sorry.

## build System

- A `WITH_CUDA` option has been added to the main CMakeLists. This finds the CUDA toolkit, and sets CUDA compiler flags, and will build unit tests for the gpu back end.
- The CMakeLists that generates mechanisms with modcc has been updated to generate CUDA mechanisms.
- the library is now named `libnestmc` instead of `libcellalgo`
- merge the external libraries that are optionally linked againts (tbb, libunwind, etc) into a single
  `EXTERNAL_LIBRARIES` list for ease of linking

## modcc

- the cprinter and cudaprinter have had small changes to generate mechanism files that are compatible with the refactored library.

## algorithms

- the indexes into algorithm was "rangified". An algorithm `index_into_iterator` takes two ranges as inputs to make a range that lazily generates the index of sub into super set.

## backends

- made a new path `src/backends/` for backend specific type and implementation code.
- currently:
  - complete support for the `multicore` and `gpu` backends
  - `gpu` back end is not optimized or validated
- the back end implementations are in `src/backends`
- a single `backend` class, `nest::mc::{multicore,gpu}::backend`, is provides all backend specific type and implementation details fro each backend
  - storage containers
  - Hines matrix assembly for FVM method
  - Hines matrix solver
  - mechanism "factory"

## lowered fvm cells

- removed `fvm_cell` because this can be modelled with an `fvm_multicell` with one cell.
- refactored to use backend type and implementation from `fvm_policy`
- use `std::vector` instead of containers in `nest::mc::memory::` where possible when building cells.

## memory library

Refactor the "memory" library, making it much simpler and better integrated into the rest of the application. However, it is still far from perfect. The `Coordinator` approach needs to be improved, most likely by putting target-specific wisdom into pointers (which could obviate the need for a `const_array_view` type.
1. renaming and moving
   - move from `vector/` to `src/memory`
   - move into the `nest::mc` namespace, i.e. all types and functions are now in `nest::mc::memory`
   - change from camel case nameing scheme to NestMC style naming.
2. simplification
   - remove the CRTP cruft that was used to make operator overloading work for operations like copying from one range into another, and filling a range with a constant value. These have been replaced with `memory::fill()` and `memory::copy()` helper functions. This simplified the code _a lot_, and makes code clearer in user land.
   
   ```
   // before
   vec(0, 5) = other;
   // now
   memory::copy(other, vec(0, 5));
   ```
   - add some wrappers in `src/memory/wrappers.hpp` that help with making views. These are particularly useful for passing `std::vector` through interfaces that expect a view.

## debug backtraces

Added stack traces for debugging.
- support for OSX and Linux via libunwind
- backtraces can be generated manually `nest::mc::util::backtrace().print()`
  - creates a new file and dumps trace into file
  - prints message to `stderr` with file name and instructions on how to analyse
- backtraces are also automatically generated when an assertion `EXPECTS` statement fails
- a python script in `scripts/print_backtrace` pretty prints the output with file name, line number and demangled symbols

## util simplification and consolidation

The `src/util.hpp` file was removed
- much of its contents were dead code and just removed
- useful components like `pprintf` and `make_unique` were moved into the `src/utils` path in standalone files
There was a lot of overlap between functionality provided in `src/memory/util.hpp` and existing functions/types in the `nest::mc::util` namespace. The `memory` implementations were removed, and their `nest::mc::util` counterparts used. There is still some work remaining, namely moving the rest of the `src/memory/util.hpp` into `src/util/...`