Change OF-888 fix to be based on error

OF-888 is presumed to be a recursion due to an attempt to bounce a bounce, in
other words it's failing to handle a double-bounce.

It appears to be caused when routing a stanza from a MUC fails, and for some
reason I don't yet understand, the routing of the bounce to the originating
MUC source also fails.

The test for the double bounce is only present for the IQ case, but this fails
in any case because it tests only for the IQ case, and uses a test which checks
the IQ's symbolic type; this is not actually set by Packet.setError(), so does
not trigger.

Tom's fix inserted a sentinel into the original failing stanza, however a new
stanza is created for the bounce, which will not contain the sentinel; therefore
the fix will not protect from a recursion.

Therefore this patch:

1) Removes Tom's fix for OF-888.

2) Tests for the message and presence error types.

3) Tests for the presence of a stanza error (though this is a warning).

4) Explicitly sets the stanza error type.

OF-901 update install4j windows bundled JRE to 1.7.0u76

OF-895 Update bundled PostgreSQL driver to 9.4-1201 JDBC4 (build 1201)

Note: this is java 1.6+ compat

ofmeet version Added focus username and password to the admin settings page

Bumped realase date

OF-858: Auto create new nodes in PEP

Updated Jitsi Videobridge

OF-858: Disco will give pubsub#auto-create for PEP

OF-858: Adding Pubsub createNode Helper

Send initial presence to the generating resource.

Openfire should return "msgoffline" in disco requests (as per XEP-0160)

OF-822: Disco request of a Non-occupant in MUC should result in bad-requ...

OF-888: Fix outgoing S2S packet delivery failure

OF-885: Use non-blocking, async API for BOSH servlet

When the invocation of the #onTimeout method of a AsyncListener does
not result in a 'complete()', then the servlet container falls back to
default processing. This causes an async response that was started in
that method to fail.

The compare() result of Deliverable was based on a field value that is never set. As a result, the compare() method will have non-specific behavior. It is likely not used at all (or if it is, a bug is looming somewhere). Removing it is the safest course of action.