Use deref to take the underlying bbqueue addr for tracing

[jamesmunns]

Have tracing report the address of the underlying storage (rather than the address of the Arc itself) so that it is easier to see related comms in traces.

Before:

  10.670354843s TRACE Kernel:Driver B:BBQueue::read_grant{queue=0x7f7758014548 side=BSide}: kernel::bbq: awaiting bbqueue read grant
  11.168783665s  WARN Kernel:Driver A: melpomene: Driver A: Reading...
  11.170023311s TRACE Kernel:Driver A:BBQueue::read_grant{queue=0x7f77580139a0 side=ASide}: kernel::bbq: Got bbqueue read grant size=4
  11.170525095s  WARN Kernel:Driver A: melpomene: Driver A: Got data buf=[245, 245, 245, 245]

After

  2.079232514s TRACE Kernel:Driver A:BBQueue::send_grant_exact{size=8 queue=0x7f08a8014700 side=ASide}: kernel::bbq: Got bbqueue exact write grant
  2.079650683s  INFO Kernel:Driver A: melpomene: Driver A: Sleeping...
  2.080172776s  WARN Kernel:Driver B: melpomene: Driver B: Reading...
  2.080742401s TRACE Kernel:Driver B:BBQueue::read_grant{queue=0x7f08a8014700 side=BSide}: kernel::bbq: Got bbqueue read grant size=8
  2.081164016s  WARN Kernel:Driver B: melpomene: Driver B: Got data buf=[1, 1, 1, 1, 1, 1, 1, 1]
  2.081413875s  INFO Kernel:Driver B: melpomene: Driver B: Writing...

[hawkw]

Ohh, I see...I thought those were the same.

[hawkw]

I think the HeapArc fmt::Pointer impl accidentally prints the address of the &self receiver when I intended it to point the actual pointed address of the arc'd storage. We should fix that upstream too...