Allow a method to disable warning on novel vendor exceptions.

[KieranBrantnerMagee]

Is your feature request related to a problem? Please describe.
If an open attempt fails with a vendor specific error, it will bubble up in such a way that will result in a logger.warning being thrown. See the following code-path:

azure-uamqp-python/uamqp/errors.py

Line 27 in 5de33fd

exception = VendorLinkDetach(condition, description, info)

azure-uamqp-python/uamqp/receiver.py

Line 184 in 5de33fd

self._error = errors._process_link_error(self.error_policy, condition, description, info)

azure-uamqp-python/uamqp/receiver.py

Lines 257 to 272 in 5de33fd

	def get_state(self):
	"""Get the state of the MessageReceiver and its underlying Link.
	:rtype: ~uamqp.constants.MessageReceiverState
	"""
	try:
	raise self._error
	except TypeError:
	pass
	except errors.LinkRedirect as e:
	_logger.info("%r", e)
	raise
	except Exception as e:
	_logger.warning("%r", e)
	raise
	return self._state

This is observed in ServiceBus when running the session_pool sample, or in the general case, timing out on opening a receiver to a session queue with no available sessions. This results in a "common/happy path scenario" that outputs to stderr, which is suboptimal to users understanding.

Describe the solution you'd like
Within UAMQP's view of the world, the above is cogent. However, for a caller, this is suboptimal, as that vendor error may be understood/handled at that level, and a warning would simply be providing more noise.

As a result, one potential solution would be to take a parameter of "known vendor specific exceptions" that are simply bubbled with no additional warning.

Describe alternatives you've considered
A flag to control logging verbosity as a whole, without tailoring it to vendor specific exceptions MAY be an option, but I'd be worried that would interfere with user expectations for how logging should behave if they did eventually want to turn it all on. Perhaps the flag could be specific to vendor specific exceptions, but that's VERY special cased, and in that case the proposed solution seems more flexible.