FCPInterface.handleSubscribe(): Catch InterruptedException

This was recently added to the throws declaration of
SubscriptionManager.subscribeToIdentities() / subscribeToTrusts() /
subscribeToScores().

We have to honor it by NOT returning a reply to the client:
- If we returned success, that would be a lie, and we shouldn't lie to
the client about being properly connected to WOT. This could cause false
display in the UI, and false bug reports because people would be
wondering why their client receives no data even though it is connected.
- If we did return failure, the client could immediately retry filing
the Subscription, which is a heavy operation, and thus block shutdown.
So we must return no reply to ensure that the client code which waits
for a success/failure reply times out to delay the retry attempt
implicitely.

Notice that this also adapts the caller of handeSubscribe() to NOT
create an success reply automatically because handleSubscribe()
returned null.
SubscriptionManagerFCPTest: Begin adapting to plugin-fcp-rewrite

- Interface PluginReplySender was part of the old pre-rewrite API. It
was used to send replies from the server plugin to the client. In the
case of this test, it was implemented to store the server messages so
the test can process them. We now change it to implement the new
interface for client-side FCP message handler, because it was being used
like a client.
- Because the interface it now implements has a more fitting name, i.e.
a name which indicates that it is a client, this commit removes the
JavaDoc which explained in detail that it is a reply receiver and not a
reply sender.
- The handlePluginFCPMessage() could now store the FCPPluginMessage
instead of only the SimpleFieldSet params because that contains more
information than the SimpleFieldSet, namely a success indicator and an
errorCode. So we add a FIXME to store it and use it in tests. First
steps is the tests to compile and succeed as is though, so this is only
a FIXME.
- The JavaDoc of handlePluginFCPMessage() instructs it to always return
a reply message if the original message was not a reply, so we do that.
I've reviewed the whole class, it doesn't seem to do anything which
needs it to indicate failure to the server, so we always return a
success reply.
SubscriptionManagerFCPTest.fcpCall(): Adapt to fred plugin-fcp-rewrite

- As I want to use the stuff for an implicit test of fred's
plugin-fcp-rewrite, this is  changed to use the actual FCPPluginClient
of fred to send the message instead of calling the message handler
directly.
- Because we used to call the message handler directly which would have
only returned after the message handler is finished, we now have to
use the blocking sendSynchronous() instead of non-blocking send() to
ensure that the reply message has  been delivered before fcpCall()
returns. Or in other words: We cannot use send() because it would queue
the sending in another thread, so the reply might not be available yet
when it returns.
- WOT should compile again now :) Next step of adapting to fred
plugin-fcp-rewrite is to run the unit tests and debug eventual issues.
After that, a DebugFCPClient test run should be done.