Exception specifications are useless for production code, but make
for useful assertions in dbgutil builds (on platforms where they
are enforced at runtime).

Because we do not have API tests that exhaustively trigger all
documented error conditions, much less the undocumented or wrongly
handled error conditions that would cause the implementation to violate
its API specification, there is likely some benefit in having these
runtime-checked specifications in debug builds, in the hope that our
various tests which may incidentally call various API methods, or
general soffice usage, uncovers these bugs.

Also, there may be some benefit to making API implementers more
aware of the exception specifications, to quote Stephan's mail:

 To be able to programmatically react to an exception raised by a UNO
 method (which is the raison d'être of non-runtime UNO exceptions), the
 specification of that method must document the method's behavior with
 respect to raising that exception, and any implementation of the method
 must adhere to that specification.  However, with that part of a UNO
 method's interface moved out of sight of a programmer writing a C++
 implementation of that method, I fear that adherence to specification
 will degrade in practice.  And that negatively affects an area where we
 do not shine anyway: reaction to errors.

This partially reverts commits:
0295bd6b
155cd09b

Change-Id: I9c7664c9f1b238f4f9501aacb065981236949440