Data storage format of indexeddb adapter: some data duplications and a possible revpos issue

### Issue
First of all thanks so much for this new 7.3.0 release!

I'm experimenting with the new `indexeddb` adapter and have discovered a few oddities. I'll list them together here, feel free to open separate tickets for them if needed.

I have created a tiny html page which pulls a remote couch, where I fed some documents into. The first document looks like this:

```json
{
"_id": "one",
"_rev": "1-28efe2e47ddaea0bf45013d342e17351",
"awesome": true
}
```
Now when I pull this, the data shows up as


Three things caught my attention:
* `data` is duplicated - once toplevel and once under the specific revision. I looked in the code and it seems that the toplevel entry is never used.
* Since the toplevel entry is presumably not used, it is probably not a problem, but I find it strange that `awesome: true` suddenly shows up here as `awesome: -9007199254740989`. Maybe this is an indicator of another problem somewhere?
* And the third thing is more cosmetic: `deleted` is here once `0` and once `undefined` - wouldn't it be nicer to use a boolean?

Now I created another document:

```json
{
"_id": "two",
"_rev": "1-967a00dff5e02add41819138abb3284d"
}
```

and uploaded an attachment at rev 2:
```json
{
"_id": "two",
"_rev": "2-c5c6930363b12fbf4aeea77c091f4bb4",
"_attachments": {
"tf.gif": {
"content_type": "image/gif",
"revpos": 2,
"digest": "md5-425oIgpsaEjkCeaAdJDgmQ==",
"length": 1450,
"stub": true
}
}
}
```

and added a modification at rev 3:
```json
{
"_id": "two",
"_rev": "3-c079b528eeec836c67fb399e5d120b3d",
"awesome": "again",
"_attachments": {
"tf.gif": {
"content_type": "image/gif",
"revpos": 2,
"digest": "md5-425oIgpsaEjkCeaAdJDgmQ==",
"length": 1450,
"stub": true
}
}
}
```
and pull-replicated again. The data shows up as:


Two attachment related things struck me here:
* `revpos` is a different one in the attachments-stub, namely `3`. Thereby the attachment was uploaded with revision `2`, which is also noted so in the attachments store.
* Here is again a data duplication: the attachment metadata `content_type`, `digest`, `length` and `revpos` are stored in the attachment store as well as under the revision. If I read the code correctly, only the latter is used. So it would be sufficient to store only `data` in the attachment store.

So these are all primarily minor things, except maybe the revpos story. I thought if we were going to introduce a new adapter as "experimental", now might be a good time to smooth that out.

:rabbit:

### Info
- Environment: browser
- Platform: Chrome
- Adapter: indexeddb
- Server: CouchDB
- Version: 7.3.0, `pouchdb.indexeddb.min.js` and `pouchdb.min.js` from https://cdn.jsdelivr.net/npm/pouchdb@7.3.0/dist/