FCPInterface.send*ChangedNotification(): Adapt to new throws declaration
of sendChangeNotification()

- Also add final attribute to variables so all of the 3 functions have
the same signature.
- FCPInterface.java should compile again now, so the basic adaption to
fred plugin-fcp-rewrite is finished for this file. A full review
of it should be done nevertheless to ensure absolute compatibility with
plugin-fcp-rewrite. But I'll first compile fix everything and just run
the unit tests to see whether it works. If it does, the review can maybe
be spared. Notice that the FIXMEs in the file need for sure be resolved
before the branch can be merged though.
FCPInterface: Throw out a specific Exception type if sendSynchronous()
succeed but processing at the remote side did not

The previous code did use IOException for both:
- sendSynchronous() failing because the connectin is dead
- sendSynchronous() succeeding, returning a reply, but the reply havign
success==false which says that the client had an error at its side.

I had previously assumed that this distinction would be of no use to the
SubscriptionManager which uses the affected functions. I thought it
would only matter to it whether it has to re-send a certain message. But
looking at the actual code now shows that it in fact already can do two
things: Terminate the Subscription immediately if the connection is
closed, and not terminate but re-send an event if only processing
failed.
So we need to use two Exception types.
SubscriptionManager: Adapt to fred plugin-fcp-rewrite Exception types

- IOException is thrown instead of PluginNotFoundException when a
send()/sendSynchronous() fails
- FCPCallFailedException is not a fred class anymore. sendSynchronous()
indicates failure at the client via FCPPluginMessage.success==false in
the returned FCPPluginMessage. Thus, FCPInterfaace now contains the
class FCPCallFailedException (because the SubscriptionManager is not
interested in any of the other FCPPluginMessage contents, and also
because this shouldn't happen frequently enough for Exceptions to become
too much of performance hogging)