Fix destruction order in LocalStorageImpl::StorageAreaHolder for BackupRefPtr

When BackupRefPtr is used for LocalStorageImpl::StorageAreaHolder::area_ptr_, the destruction order of the fields causes a null dereference.

~StorageAreaHolder() ends up calling StorageAreaHolder::PrepareToCommit() which tries to use area_ptr_ without a null check

Bug: 1080832
Change-Id: Iff06bbf440eb5a3d26226c85b13b36ac037f1fca
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2564932Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Bartek Nowierski <bartekn@chromium.org>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Commit-Queue: Keishi Hattori <keishi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#834641}

components/services/storage/dom_storage/local_storage_impl.cc

@@ -431,12 +431,12 @@ class LocalStorageImpl::StorageAreaHolder final
 
   LocalStorageImpl* context_;
   url::Origin origin_;
-  std::unique_ptr<StorageAreaImpl> area_;
   // Holds the same value as |area_|. The reason for this is that
   // during destruction of the StorageAreaImpl instance we might still get
   // called and need access  to the StorageAreaImpl instance. The unique_ptr
   // could already be null, but this field should still be valid.
   StorageAreaImpl* area_ptr_;
+  std::unique_ptr<StorageAreaImpl> area_;
   bool deleted_old_data_ = false;
   bool has_bindings_ = false;
 };