Fix logic around calling wait_on_close

[jtratner]

1. Only call it when we've written data (i.e., there's a buffer) - fixes issues where destructor was throwing errors. (came up when watching travis logs)
2. Only call it for WRITE_MODES (this should potential issue where holding a DX file object in read mode would cause an extra API request).

I'd like to double check this, but my belief on reading this is that we were previously making an additional API request to DNAnexus every time we attempted to read a DXFile object (rather than only doing it on writes).

[jtratner]

Yay - no more of these errors!

Previous:

test_append_mode_fail (stor.tests.test_dx.TestOpen) ... Exception ignored in: <bound method OBSFile.__del__ of <stor.obs.OBSFile object at 0x7f0ea4560080>>
Traceback (most recent call last):
  File "/home/travis/build/counsyl/stor/stor/obs.py", line 408, in __del__
    self.close()
  File "/home/travis/build/counsyl/stor/stor/obs.py", line 464, in close
    self._wait_on_close()
  File "/home/travis/build/counsyl/stor/stor/obs.py", line 467, in _wait_on_close
    if isinstance(self._path, stor.dx.DXPath):
AttributeError: 'OBSFile' object has no attribute '_path'

New:

test_append_mode_fail (stor.tests.test_dx.TestOpen) ... ok

woo!

[jtratner]

@anujkumar93 - if you end up regenerating cassettes would be interesting to see if we have one fewer API request with this (and whether worth writing a test case for that portion of the behavior).

Otherwise relatively hard to test "did not error out in del" :-/

[jtratner]

maybe a test with a mock that shows read mode no longer calls wait_on_close ever!