[IndexedDB] Inform script of corruption recovery

We'd like to add a mechanism to the IndexedDB API that would allow script
to be notified in case of data corruption.

Now that IDB adoption has been ramping up we've been getting manual and
automated reports of storage corruption. This has led us to find some
implementation bugs, but on commodity hardware in real-world conditions,
this is a scenario we can't ignore. We've seen this with different backing
store technologies and different subsystems, so IDB is not going to be
immune.

When chrome opens an IDB database, it attempts to detect corruption. If the
database appears to have been corrupted, either via software bug or
hardware fault, chrome performs "recovery." As currently implemented (we
may try to do something more surgical in the future), "recovery"
means removing all the origin's databases from disk and creating a new
empty database. It would be useful to alert script that some data has been
lost in this situation. The web app could then alert the user or take other
appropriate action. This is important in offline editing scenarios, where
this represents true user data loss rather than just a flush of a data
cache.

Some options we've discussed:
* Do nothing; web apps could mirror the latest version in localStorage and
look for discrepancies.
Pro: No changes to the IDB API.
Con: Lame to make web developers rely on another storage mechanism to
handle IDB corruption.

* Report to the user via pop-up, not script
Pro: No changes to the IDB API.
Con: Opaque to the web app. Not actionable to the user. Prevents any
app-level appropriate response.

* Property on the upgradeneeded event. If a corrupt database was blown
away, oldVersion would be 0 but a "reason" property could indicate
corruption; and similarly,
* Property on IDBDatabase indicating if recovery had to be performed during
opening (e.g. "dataLoss" with values "none", "total", and potentially
"partial")
Pro: Surfacing error to the app allows for app-specific action or options
presented to the user.
Con: Not very elegant, the extra property is wart-like.

* Change open flow - in case corruption is detected, open fails with
diagnostic error, but can be retried by script e.g. indexedDB.open(name,
version, { recover: true }) - i.e. what chrome does automatically/silently
for scripts today
Pro: Gives app control over how to handle corruption.
Con: Complex. Until implementations perform a nuanced recovery, the extra
control isn't terribly useful.

We've been leaning toward the extra property on IDBDatabase or the
upgradeneeded event but are interested in hearing opinions.

Regardless of the exact form the mechanism takes, we're interested in
implementing it, potentially only in -dev builds, getting developer
feedback, and reporting our experience so that this can get included in v2
of the IDB spec.