chore(deps): update Cargo.lock for dependency bumps

[davehorner]

Bump Cargo.lock version from 3 to 4 and update dependency versions:

• autocfg: 1.1.0 → 1.4.0 (with updated checksums)
• num-bigint: 0.1.44 → 0.1.45
• num-complex: 0.1.43 → 1.1.44
• num-rational: 0.1.42 → 0.1.43

rust-num/num-bigint#321 this issue also occurs on Windows.

I haven't yet tested this fix on mac, but I will.
I don't understand one thing,

I chased my tail a bit on rubato.

cargo update -p [email protected] --precise 0.1.43
    Updating crates.io index
error: failed to select a version for the requirement num-complex = "^0.3"
candidate versions found which didn't match: 0.1.43
location searched: crates.io index
required by package rubato v0.5.2
    ... which satisfies dependency rubato = "^0.5.0" (locked to 0.5.2) of package hrtf v0.2.0
    ... which satisfies dependency hrtf = "^0.2" (locked to 0.2.0) of package examples v0.1.0 (C:\w\nannou\examples)

rg rubato
Cargo.lock
2110: "rubato",
4433:name = "rubato"

 448   │ ├── hrtf v0.2.0
 449   │ │   ├── byteorder v1.5.0
 450   │ │   ├── rg3d-core v0.10.0
 451   │ │   │   ├── base64 v0.12.3
 452   │ │   │   ├── byteorder v1.5.0
 453   │ │   │   ├── lazy_static v1.4.0
 454   │ │   │   ├── memoffset v0.5.6 (*)
 455   │ │   │   └── rand v0.7.3 (*)
 456   │ │   ├── rubato v0.5.2
 457   │ │   │   ├── log v0.4.20
 458   │ │   │   ├── num-complex v0.3.1
 459   │ │   │   │   └── num-traits v0.2.17 (*)
 460   │ │   │   ├── num-integer v0.1.45 (*)
 461   │ │   │   ├── num-traits v0.2.17 (*)
 462   │ │   │   └── realfft v0.3.0
 463   │ │   │       └── rustfft v4.1.0
 464   │ │   │           ├── num-complex v0.3.1 (*)
 465   │ │   │           ├── num-integer v0.1.45 (*)
 466   │ │   │           ├── num-traits v0.2.17 (*)
 467   │ │   │           ├── strength_reduce v0.2.4
 468   │ │   │           └── transpose v0.2.2
 469   │ │   │               ├── num-integer v0.1.45 (*)
 470   │ │   │               └── strength_reduce v0.2.4

the rubato dependency pulls in an old 0.3.1 of complex.
I'm not sure how to get this updated... it turns out this is not required to get the wgpu to compile on windows.