Fix crash in StorageManager destructor when GlobalState init fails
Fix crash in StorageManager destructor when GlobalState init fails

- After the previous patch to change initialization order, if GlobalState::init fails
  then the StorageManager may be left in a partially initialized state. If the
  StorageManager destructor is then called to clean up, we must avoid calling
  VFS operations.

  Bug description:
  In the TBB tests, we try initializing TBB with thread_count = -3. This
  properly fails, in the GlobalState::init call, leading to destruction of the
  Ctx object, here:
  - https://github.com/TileDB-Inc/TileDB/blob/1ff92bda90921df0ab6e1a44dec88dd5d26bf998/tiledb/sm/c_api/tiledb.cc#L1113-L1114
  https://github.com/TileDB-Inc/TileDB/blob/dev/tiledb/sm/c_api/tiledb.cc#L1114

  which then calls the StorageManager destructor, which makes several
  calls on the `vfs_` object:

  - https://github.com/TileDB-Inc/TileDB/blob/b175d59bcea9ca243e060445bbd14d308681a155/tiledb/sm/storage_manager/storage_manager.cc#L77-L98

  These calls fail, because with the patched initialization order in the
  previous commit, VFS has not been assigned or initialized and is
  nullptr.

TileDB-Inc/TileDB,TileDB-Inc/TileDB,TileDB-Inc/TileDB,TileDB-Inc/TileDB