Revert of Require FilePathWatcher destructor to be called in sequence with Watch().

Revert of Require FilePathWatcher destructor to be called in sequence with Watch(). (patchset #10 id:180001 of https://codereview.chromium.org/2438913003/ )

Reason for revert:
I'm sorry, but I'm pretty confident that this patch is causing some trybot flakes.

See: https://bugs.chromium.org/p/chromium/issues/detail?id=665511

Flakes link:
https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyVAsSBUZsYWtlIklQaWNhc2FEYXRhUHJvdmlkZXJOb0RhdGFiYXNlR2V0QWxidW1zSW1hZ2VzVGVzdC5Ob0RhdGFiYXNlR2V0QWxidW1zSW1hZ2VzDA

Original issue's description:
> Require FilePathWatcher destructor to be called in sequence with Watch().
> 
> file_path_watcher_win.cc and file_path_watcher_kqueue.cc need to do
> some cleanup on the sequence from which Watch() is called. They use
> destruction observers to do this cleanup when the MessageLoop from
> which Watch() is called is destroyed (after that, it is too late to
> post tasks to the MessageLoop sequence).
> 
> With this CL, the FilePathWatcher destructor must be called on the
> sequence from which Watch() is called. That means that will be able
> to move the work done in MessageLoop destruction observers to the
> FilePathWatcher destructor. Getting rid of destruction observers in
> FilePathWatcher is important because they are not supported in
> TaskScheduler.
> 
> TBR=scottbyer@chromium.org
> BUG=650723
> 
> Committed: https://crrev.com/1ce19c6494518bcc1cc1fd4b2bfc73e6f6e41fa0
> Cr-Commit-Position: refs/heads/master@{#431921}

TBR=scottbyer@chromium.org,dcheng@chromium.org,thestig@chromium.org,fdoray@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=650723

[tommycli, 2016-11-19 00:27:53]

The CQ bit was checked by tommycli@chromium.org

[tommycli, 2016-11-19 00:27:54]

Created Revert of Require FilePathWatcher destructor to be called in sequence
with Watch().

[commit-bot: I haz the power, 2016-11-19 00:28:30]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-19 00:50:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-19 00:50:07]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[fdoray, 2016-11-21 15:39:53]

lgtm

[Lei Zhang, 2016-11-21 19:07:54]

This didn't actually land and Tommy won't be back until tomorrow.

[fdoray, 2016-11-21 19:16:17]

On 2016/11/21 19:07:54, Lei Zhang (Mostly OOO) wrote:
> This didn't actually land and Tommy won't be back until tomorrow.

PicasaDataProviderNoDatabaseGetAlbumsImagesTest.NoDatabaseGetAlbumsImages fails
when PicasaDataProvider is destroyed before OnTempDirWatchStarted() is invoked.
When that happens, the FilePathWatcher is destroyed on the media sequence
instead of on the FILE thread.

This CL fixes the problem https://codereview.chromium.org/2518053002 Would it be
possible to land it directly instead of reverting the CL that caused the problem
https://codereview.chromium.org/2514113003/ and re-landing it with the fix
applied?

[Lei Zhang, 2016-11-21 19:25:30]

On 2016/11/21 19:16:17, fdoray wrote:
> On 2016/11/21 19:07:54, Lei Zhang (Mostly OOO) wrote:
> > This didn't actually land and Tommy won't be back until tomorrow.
> 
> PicasaDataProviderNoDatabaseGetAlbumsImagesTest.NoDatabaseGetAlbumsImages
fails
> when PicasaDataProvider is destroyed before OnTempDirWatchStarted() is
invoked.
> When that happens, the FilePathWatcher is destroyed on the media sequence
> instead of on the FILE thread.
> 
> This CL fixes the problem https://codereview.chromium.org/2518053002 Would it
be
> possible to land it directly instead of reverting the CL that caused the
problem
> https://codereview.chromium.org/2514113003/ and re-landing it with the fix
> applied?

Sure. I'll take a look...