Make ITK exceptions and their tests specific

### Description

ITK **exceptions** are largely **non-specific**, i.e. a general `itkExceptionMacro` can loosely used to throw virtually any type of exception. Making exceptions be more specific, including the messages, would make the toolkit more consistent.

At the same time, the `TRY_EXPECT_EXCEPTION` macro is **non-specific**, meaning that it **expects the statement to throw an exception, whichever the exception is**. **When writing such a statement in a test, the programmer generally expects a specific exception to be caught**, i.e. an exception with a known message to be thrown. However, **if the code is not designed correctly or hides a bug, the statement may well catch an exception, but one that has been thrown elsewhere/is different from the one expected**. **The test or macro would work correctly**, because it does not check the exception type (or better, the source of the exception, or both).

PR #511 [uncovered such a situation](https://github.com/InsightSoftwareConsortium/ITK/pull/511#issuecomment-497877457).

### Impact analysis

Having non-specific exceptions provides a flexible framework, but may hide bugs. Also, if there is no way to check the exception type and/or the class that threw it, when expecting an exception, any other exception thrown in the call stack may be considered as a valid exception

### Expected behavior

Creating a specific set of exceptions and enhancing the `TRY_EXPECT_EXCEPTION` to accept the class and exception type would help in making the code more consistent, and robust.

e.g.
```
TRY_EXPECT_EXCEPTION( filter->Update(), FilterClass, ExceptionType );
```

### Actual behavior

Current exception checking:
```
TRY_EXPECT_EXCEPTION( filter->Update() );
```

### Versions

`master`.

### Additional Information

None.