Consider making Fathom async

[biancadanforth]

Closing issue #118 provided a correctness but only small performance improvement (~13%) to Fathom-related jank in Price Tracker (which is dominated by calls to isVisible as perhaps many rulesets would be).

In that issue, we limited the isVisible improvement to a synchronous implementation. What I learned (second section) as part of that performance exploration is that simply by changing when isVisible is executed (i.e. running it async), we can reduce Fathom-related jank by upwards of 40%. This would be on top of any performance gains by changing the implementation itself (such as the 13% mentioned above).

We discussed optionally adding an async pre-processing step, though my suspicion is that that alone won't be enough, as we would still have a large chunk of main-thread-blocking, sync code execution on the order of 10s or even 100s of ms depending on the complexity of the ruleset.

Further, there may be instances, as in Price Tracker, where we want to run Fathom multiple times on a page if the page changes or if the earliest attempt is unsuccessful.

Therefore, it would be wise to pursue some ways to make all or part of Fathom async, to ensure we minimize or chunk up the jank especially at critical times like during page load, if the user is scrolling, etc.

One option is to execute Fathom on the page during browser idle times, though for some applications, this may be too late for the results to be useful.