MCOP-522 default max_hbrlck_fails to 0

As more users are adopting STOMP 1.1 heart-beats we're seeing suprious
disconnections caused by the default value of max_hbrlck_fails (2).

In the MCollective use-case we typically expect there will be
receiving thread reading the socket for the next message from the
middleware.  This will hold the stomp readlock and so will cause
hbrlck_fail events (the heartbeat thread is contending with the
main receive thread).  We expect this as a usage pattern, so the
safest thing to do in MCollective is to default max_hbrlck_fails
to 0, which disables this test in the stomp gem.
MCOP-522 Do not log at error for hbrlck if we have set no max

Here we add some more logic to the logger callback.  If max_hbrlck_fails
is not set, then the { 'lock_fail' => true } messages are informational,
so we log those at debug.  If it's enabled then we log at warn until the limit
is reached, when we log at error.
Merge pull request #268 from richardc/MCOP-522-heartbeat_defaults

MCOP-522 revisit heartbeat defaults