Improve exceptions hierarchy and usage

[Luthaf]

This spawn up from a comment by @max-veit, that some exceptions should never be triggered, because the parameter combination should have been handled elsewhere. The message associated with these exceptions should make that clear, like in

https://github.com/cosmo-epfl/librascal/blob/deb7a09bed3e8713267a364cd742687eb28aaa8c/src/representations/calculator_spherical_expansion.hh#L1028-L1039

---

One possible way to fix this is to introduce rascal specific exception types:

namespace rascal {
struct error: public std::runtime_exception {
    error(std::string message): std::runtime_exception(message) {}
};

struct internal_error: public error {
        internal_error(std::string message): error("internal error, this is a bug: " + message) {}
};

And then use rascal::internal_error for, well, internal errors, and rascal::error for other cases. Other sub-classes can be introduced as needed.

---

Then, as a further step, a macro can be introduced to capture local info for debug variables, backtrace, etc.

[Luthaf]

Introducing rascal specific exception allow C++ users of the library to handle these exceptions separately from std::exception if they want, and since they inherit from std::exception they will be caught in a catch (const std::exception& e) arm.

[max-veit]

Sure, sounds like a good idea in principle.