fix MDB tests

* with JMS 2.0, the behaviour of ConnectionFactory.createSession() has
been clarified:

> In a Java EE web or EJB container, when there is an active JTA
> transaction in progress:
>
> Both arguments transacted and acknowledgeMode are ignored. The session
> will participate in the JTA transaction and will be committed or rolled
> back when that transaction is committed or rolled back, not by calling
> the session's commit or rollback methods. Since both arguments are
> ignored, developers are recommended to use createSession(), which has no
> arguments, instead of this method.
> In the Java EE web or EJB container, when there is no active JTA
> transaction in progress:
>
> The argument transacted is ignored. The session will always be
> non-transacted, using one of the two acknowledgement modes
> AUTO_ACKNOWLEDGE and DUPS_OK_ACKNOWLEDGE.
> The argument acknowledgeMode is used to specify how messages received by
> this session will be acknowledged. The only permitted values in this
> case are Session.AUTO_ACKNOWLEDGE and Session.DUPS_OK_ACKNOWLEDGE. The
> value Session.CLIENT_ACKNOWLEDGE may not be used. For a definition of
> the meaning of these acknowledgement modes see the links below.

However, the MDB contract in EJB 3.2 spec (§ 5.4.6) specifies that:

> The PostConstruct lifecycle callback interceptor method executes in an
> unspecified transaction and security context.

This means that the behaviour of ConnectionFactory.createSeesion is
unspecified in @PostConstruct since the transaction context is itself
unspecified.

After some debugging, it appears that in WildFly, there *is* a
transaction when @PostConstruct method is called. This implies that the
JMS session is created to participate in *this* transaction.

Later on, when the MDB's `onMessage()` is called, it is in *another*
transaction and the JMS session will not participate (meaning the reply
message is not sent and the tests failed)

It was working before with JMS 1.1 because the JMS sessions was not transacted
(the createSession contract was not specified) and the message was sent
outside of the transaction required by the MDB's `onMessage()` method.

Creating a JMS context (equivalent to a connection + session) inside the
`onMessage()` method makes sure the JMS session is created with a
correct transaction context.
In addition, there is no benefit to keep the JMS connection as a MDB
field since it's using a pooled connection.