By wrapping ResponseErrorException with another layer in
RuntimeException it means the unwrapping of the exception in
RemoteEndpoint.DEFAULT_EXCEPTION_HANDLER doesn't work as
expected and instead of getting the original ResponseError
the other end gets the fallback ResponseError of type
internal error.

This change includes updates to documentation to show that
it is ok to throw ResponseErrorException (reverts #578).
While it is also OK to return an exceptionally completed
future, it is not needed to do that way and simply throwing
is more straightforward.

There are new tests to cover the changed handling. Also tested
is the previously documented way of handling exceptions (see
`tries == 1` case in `testVersatility` and `testVersatilityResponseError`

Fixes #802

Also-by: Vladimir Piskarev <pisv@1c.ru>

This exception is thrown when the endpoint is created, not as a result of
a receiving a message. This is generally a coding error, so make this
exception the same as the other exceptions thrown by recursiveFindRpcMethods.

Included is adding additional tests to ensure coverage of some
previously missing uses cases.

Code cleanup done as part of #802

Checked exceptions should not be thrown from annotated jsonrpc methods.
Such exceptions can be treated as a programming error, and signaled via
an IllegalStateException in the GenericEndpoint.

An inaccessible jsonrpc method can be handled in a similar way.

For detailed discussion and context, see
#809 (comment).