Improve large watcher events payload experience

[mattcompiles]

↪️ Pull Request

On large projects after branch changes or yarn installs the watcher can take a very long time to respond with the changed files. The cache invalidation in respondToFSEvents can then often take an extremely long time to process all the events. This PR attempts to make the experience nicer with the following changes:

• Add a timeout threshold to RequestGraph.respondToFSEvents which will result in using a fresh cache if it times out
  • This has been implemented by attempting to predict how long the events will take to process by extrapolating the time taken to process a small batch of events. It's currently set to 10 seconds.
• Move the project relative file events logic to respondToFSEvents, this ensures we don't do extra work when bailouts occur
• Add a warning to notify users that the watcher is taking a long time to respond if it takes more than 5 seconds. This helps reassure users that the build is not actually stuck.

I've also added bonus change. I've added a new meta property to the Diagnostic type. This allows us to forward extra information to our reporters from the logger for analytics purposes.

logger.warn({
  origin: '@parcel/core',
  message: 'Building with clean cache. Cache invalidation took too long.',
  meta: {
    trackableEvent: 'cache_invalidation_timeout',
    watcherEventCount: events.length,
    predictedTime,
  },
});

✔️ PR Todo

• Added/updated unit tests for this change
• Filled out test instructions (In case there aren't any unit tests)
• Included links to related issues/PRs