Use of int64, uint64, float64 in the HTTP API

### Checklist

- [X] This is a bug report, not a question. Ask questions on [discuss.ipfs.io](https://discuss.ipfs.io).
- [X] I have searched on the [issue tracker](https://github.com/ipfs/go-ipfs/issues?q=is%3Aissue) for my bug.
- [X] I am running the latest [go-ipfs version](https://dist.ipfs.io/#go-ipfs) or have an issue updating.

### Installation method

built from source

### Version

_No response_

### Config

_No response_

### Description

The HTTP API docs for `/api/v0/stats/bw` say `RateIn` and `RateOut` are `float64` and `TotalIn` and `TotalOut` are `int64`.

They are returned as numbers from the API:

```console
$ curl -X POST http://127.0.0.1:5002/api/v0/stats/bw
{"TotalIn":382097,"TotalOut":219659,"RateIn":5594.9794181522075,"RateOut":74.06595710119922}
```

If we need this amount of precision, these should be returned as stringified numbers instead, otherwise some implementations (eg. `JSON.parse` in js) will not be able to parse them, since their native number type does not have enough precision to do so:

```js
JSON.parse('{"TotalIn": 107654321001234567800}')
// {TotalIn: 107654321001234560000}
```

If they are returned as strings they can be converted into `BigInt`s by client libraries and the correct values will be retained.

This applies to the following endpoints:

* /api/v0/add
* /api/v0/bitswap/ledger
* /api/v0/bitswap/stat
* /api/v0/dag/stat
* /api/v0/file/ls
* /api/v0/files/ls
* /api/v0/files/stat
* /api/v0/filestore/ls
* /api/v0/filestore/verify
* /api/v0/ls
* /api/v0/object/get
* /api/v0/object/links
* /api/v0/object/new
* /api/v0/object/patch/add-link
* /api/v0/object/patch/append-data
* /api/v0/object/patch/rm-link
* /api/v0/object/patch/set-data
* /api/v0/object/put
* /api/v0/repo/stat
* /api/v0/stats/bw
* /api/v0/stats/bitswap
* /api/v0/stats/repo
* /api/v0/tar/add