Update API spec in explainer to match latest discussion

[mingyc]

• Fix Should pageHideTimeout support additional events #13:
  • Replace pageHideTimeout with backgroundTimeout and timeout.
  • Allow to set them in constructor & sub-class's setData() or setURL().
• Fix isPending's value is unclear after deactivate() #11: Rename isPending to pending and specify its
  behaviors.
• Address Request for comment on API shapes #9: Keep the low-level sync API, and mark it as chosen.
• Fix Should setData(data) only support POST request #6:
  • Add PendingGETBeacon which supports setURL(url, options).
  • Add PendingPOSTBeacon which supports setData(data, options).
  • Remove setData(data) from base PendingBeacon.

[mingyc]

cc @philipwalton @fergald PTAL. Please also suggest better naming than PendingGETBeacon, PendingPOSTBeacon, thanks!

[fergald]

I think in the case of

Tab A: top level is userfoo.blog.com, frame is map.company.com
Tab B: top level is map.company.com

I think Tab A's map.company.com beacons should still be delivered because

1. that frame can't create new beacons, the data was put into the beacons before it entered BFCache, it could have sent them immediately, wasting radio, quota, CPU etc, instead it used a beacon with a delay to try save resources in the case that comes back out quickly.
   Or to put it another way, there is no user expectation being violated about what data is sent.
2. It's hard to argue that the user has any expectation about when the data is sent since beacon is write-only but since map.company.com is open in another tab, having connections occur to its servers does not seem to violate expectations.

In general I would really like to not impose restrictions on beacon that are not present already because all that does is keep devs doing things the hard way which also tends to be wasteful of user resources.