Fixed parsing objdump output where symbol addrs include "0x"

[bjackman]

For one reason or another with my version of GNU objdump, symbol headers are printed like this:

0x3bc80000 <foo>:

While the current regex appears to assume it will show up like this:

3bc80000 <foo>:

This results in the following crash:

Traceback (most recent call last):
  File "/home/brendan/sources/elf_diff/bin/elf_diff", line 46, in <module>
    generatePairReport(settings)
  File "/home/brendan/sources/elf_diff/bin/../python/elf_diff/pair_report.py", line 405, in generatePairReport
    PairReport(settings).generate()
  File "/home/brendan/sources/elf_diff/bin/../python/elf_diff/pair_report.py", line 38, in __init__
    settings.new_binary_filename)
  File "/home/brendan/sources/elf_diff/bin/../python/elf_diff/binary_pair.py", line 41, in __init__
    self.old_binary = Binary(self.settings, self.old_binary_filename)
  File "/home/brendan/sources/elf_diff/bin/../python/elf_diff/binary.py", line 44, in __init__
    self.parseSymbols()
  File "/home/brendan/sources/elf_diff/bin/../python/elf_diff/binary.py", line 139, in parseSymbols
    cur_symbol.addInstructions(instruction_line_match.group(1) + instruction_line_match.group(2))
AttributeError: 'NoneType' object has no attribute 'addInstructions'

Where we match an instruction line but have no symbol to attribute the instruction to.

Add the '0x' optionally to the regex to avoid this.

[noseglasses]

Sorry for this hanging around for so long.