Resetting mappings during refresh to pick up newly added portable types

- This broke about a year ago: 63e9fd5637d433b1d2939b87060b3ac5cd1b65a6
ERRAI-449: Remove unused ConverationalEventImpl
Cleaned up Sender<T> support in errai cdi to not introduce dependency on Weld
Removed ScopeUtil to get rid of a dependency to weld internals

- Its purpose is unclear to us: The tests and demos don't seem to be affected by removing it
- The theory is that the async dispatcher (which is no longer used with errai-cdi) necessitated associating the servlet request with Weld's request context because it separated the incoming request thread from the actual worker thread
Fixed ERRAI-657: Weld warning for ErraiServiceBean and MessageBusBean
Fixed ERRAI-656: Silence WELD warning of ErraiService missing constructor
Changed fix for ERRAI-591 to not introduce dep. on Weld and also work with WildFly 8.Beta1
Work in progress on the bus retry backoff fixes + tests
Fixed ERRAI-687: gradual backoff during reconnect attempts

I've introduced a test for this in the 404 error case. Unfortunately, there is logic in the client bus that does different things depending on the specific status code in the response. Testing all HTTP status codes is unfortunately prohibitive: it takes about 20 seconds per test, so we'll have to settle for partial coverage.

The new test also uncovered a problem with HttpPollingTransportHandler: it wasn't actually cleaning up all its timers when the bus told it to stop. This is fixed now too.

The fixes I made to the code itself, then:

* ClientMessageBusImpl.init() will now delay for a growing amount of time when there hasn't been a successful connection attempt in a while
* Fixed leaking timers in HttpPollingTransportHandler that persist after the bus has stopped and apparently thrown the whole transport handler away

It would be nice to randomize the existing throttling mechanism in the transport handlers. It would be even nicer to wire the transport handlers into the bus's own backoff mechanism, since the various handlers seem to operate independently at the moment.
Undoing backoff logic in ClientMessageBusImpl.init() because it was interfering with a weld-integration test

Note that the original TransportHandler backoff is still in place, as is the test that protects it.
Removed logger that's not used
Removed unneeded war directory
Upgrading to latest jboss-integration-platform-parent
Allow java.util.Date as @Param type
Updated to new version 2.4.4.Final
Updated to new version 2.4.5-SNAPSHOT