Repository: tauri
Issue: Incorrect Representation of u/i64 as JS Number - Floating Point Rounding Bug
Labels: type: bug,status: needs triage

### Describe the bug

I'm running into an issue where larger i64 values hit floating point precision failures in JS Number pretty quickly when used in command args or when returned back out from commands. See attached screenshots - in the first, I have serialized the i64 to strings before being returned from commands, resulting in the desired behavior, and in the other, the i64 values are simply returned, resulting in floating point rounding issues.

As a simple example:

```js
// 4294967295 is u32::MAX, serializes just fine
> Number(4294967295)
4294967295
// 856386184130166833 is not even a particularly large i64 value, but we can see it fails to be correctly represented as a JS number
> Number(856386184130166833)
856386184130166800
```

And for a real-world example in my application:

Naievely serializing i64
![image](https://user-images.githubusercontent.com/22972550/232332586-a10415f8-845b-4250-88bf-0e917a22e808.png)

Explicitly serializing to Strings
![image](https://user-images.githubusercontent.com/22972550/232332568-26f05484-bae8-4c44-b932-88f9c70d5368.png)




### Reproduction

For a simple example of the issue with JS floating point numbers:
```js
// 4294967295 is u32::MAX, serializes just fine
> Number(4294967295)
4294967295
// 856386184130166833 is not even a particularly large i64 value, but we can see it fails to be correctly represented as a JS number
> Number(856386184130166833)
856386184130166800
```

For a Tauri example, return a number in the range of `856389119771188367` from a Tauri command and see how it is displayed

### Expected behavior

I'd expect that values returned from a command to have the same value when used in a later command. This expectation falls down in the case of serialized u/i64 numbers. 

### Platform and versions

```text
Environment
  › OS: Windows 10.0.19044 X64
  › Webview2: 112.0.1722.39
  › MSVC: 
      - Visual Studio Community 2022
  › Node.js: 16.17.0
  › npm: 8.15.0
  › pnpm: 7.29.1
  › yarn: 1.22.4
  › rustup: 1.25.2
  › rustc: 1.67.1
  › cargo: 1.67.1
  › Rust toolchain: stable-x86_64-pc-windows-msvc 

Packages
  › @tauri-apps/cli [NPM]: 1.2.3
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Error("unexpected character 't' while parsing major version number")', src\info.rs:566:67
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

(There's some bug in this tauri command??? Idk)

		"@tauri-apps/api": "^1.2.0",
		"@tauri-apps/cli": "^1.2",
tauri-build = { version = "1.2.1", features = [] }
tauri = { version = "1.2.4", features = ["devtools", "shell-open"] }

```


### Stack trace

_No response_

### Additional context

I propose that the `CommandItem` deserializer, as well as the serialization mechanism to serialize responses back to the js UI, be modified to explicitly format i64 and u64 types as strings. The other option would be to use a JS BigInt, however since we're going though JSON as a serialization format, this isn't really an option as I'm not familiar with a way to explicitly encode a JS BigInt in JSON and still have the JS `JSON.parse()` func correctly extract it as .

I'm not able to follow where in Tauri the re-serialization of command responses lives, as rust-analyzer isn't actually able to fully expand the `command` macro, but this would fix the numeric stability of these number types with respect to the JS side and allow things such as DB IDs to be safely passed to JS land and back without numeric stability issues.

For deserialization, it would be as simple as changing this: https://github.com/tauri-apps/tauri/blob/dfb5f52d3cbe44ce4607cd875b9632093b9123b1/core/tauri/src/command.rs#L104 to not use pass and instead use `String::deserialize(deserializer)?.parse().map_err(de::Error::custom)` and then using `      serializer.collect_str(value)` whwerever the serialization hardware is located.

I don't believe this to be a breaking change, as currently serialization of u/i64 is already inherently unsafe, so I think it could be a patch?? If others agree I can make a PR for this soon, although I'd appreciate some pointers as to where the re-serialization of command responses actually lives in the codebase.