templates: Add BlueZ 5 and OBEX templates

These templates are moderately well featured, though currently targeted
exclusively at testing OBEX vCard transfers from phones to computers.
They could easily be extended in future to test other use-cases.
Always save templates instantiated using AddTemplate

As well as saving them when specified on the command line and through the Python API. This is necessary to fix use of templates in test cases (which are entirely instantiated over D-Bus).
Fix ObjectManager module instantiation in spawn_server_template()
Fix ObjectManager instantiation when creating an object through AddTemplate

The ObjectManager interface needs to be instantiated in that case too.
Add log output for Get, GetAll and Set D-Bus methods
Add unit tests for the ‘bluez5’ template

These cover all functionality of the template, calling bluetoothctl to check device enumeration and properties. They do not cover the ‘bluez5-obex’ template, as there is no command line utility for managing OBEX transfers.
Rearchitect Transfer management in the bluez5-obex template

The pbap-client program expects the Transfer.Filename property to always be
available and always set to the transfer filename. This makes sense, so
rearchitect Transfer handling so that the filename is specified in the
TransferCreated mock signal, and the test driver code writes to this file
throughout the transfer, calling UpdateStatus on the transfer for each write
it wishes to make known to the software under test.
Add dummy return values to some PBAP methods

These methods are not used in the libfolks code under test, but are used
by the pbap-client test program, so give them dummy implementations to
avoid crashes in the template code.
Add unit tests for the ‘bluez5-obex’ template

These cover all functionality of the test in a single test, since the
template is fairly limited at the moment.

The tests use the pbap-client test program which comes with BlueZ. This
program is not installed by BlueZ, so must be manually copied into the
user’s PATH before the bluez5-obex tests will run.

This seems to be unavoidable, due to the lack of any other available
programs which use Bluetooth PBAP.
Emit PropertiesChanged on calling the PairDevice method

This better replicates the actual BlueZ behaviour.
Add a BlockDevice method to the bluez5 template

This can be used to block a Bluetooth device. The inverse is to call PairDevice again, which marks the device as unblocked.
Add [Disc|C]onnectDevice methods to the bluez5 template

These can be used to connect and disconnect a Bluetooth device without affecting its pairing status.
Merge with trunk
Ignore build directory
Add Python coding line to BlueZ files
Fix BlueZ files to conform to PEP8
Improve test_bluez reliability by forcing bluetoothctl to list devices first

The BlueZ tests aren’t currently very reliable because bluetoothctl doesn’t block on enumerating all existing Bluetooth devices (over D-Bus) before processing commands. Try and encourage it to do this by running the ‘list’ command to get all devices before running the command the unit test actually cares about.

This still isn’t perfect, but does improve test reliability enough to be able to reduce the sleep time.
Only spawn python-dbusmock on test_bluez class initialisation

…instead of killing and re-spawning it for every unit test. This makes use of the new Reset() mock method.
.bzrignore: Add ./build
Add templates for BlueZ 5 and BlueZ-OBEX

These templates are moderately well featured, though currently targeted
exclusively at testing OBEX vCard transfers from phones to computers.

Thanks Philip Whitnall!