feat: arbitrary precision

[sodiboo]

i've made the test code a bit nicer:

• mainly, the test output directory is now in target/tmp of the actual cargo workspace, instead of target/test_outputs in the repo root. (i have my clone of this repo in a workspace; so this was bugging me)
• some test failures are also easier to read now. this uses the fancy feature of miette, but it's only in test code. jsonkdl itself is still minimal, depending only on serde_json and kdl.

---

• i added tests for arbitrary precision, and then implemented arbitrary precision.
• in doing so, i ended up undoing 2107289, since those two methods aren't actually separable due to value_repr being part of the KdlEntry.
  • they also can't be separate if there's going to be a special sentinel value field for #inf/#-inf/#nan like i proposed in correctness: exotic IEEE-754 values #8

---

• when formatting the value_repr, we also need to insert a leading space in the entry. this is normally implicit, but not with a custom value_repr.
  • see using value_repr is clunky, as it forces me to think about document formatting kdl-org/kdl-rs#130
• some of the tests fail to parse the resulting KDL document. i looked at the outputs manually, though, and i'm confident the program behaves correctly and generates valid KDL; it's just that kdl-rs fails to parse it.
  • see Large numbers fail to parse kdl-org/kdl-rs#131

[sodiboo]

lmao https://github.com/joshprk/jsonkdl/actions/runs/16548564711/job/46799978335?pr=9

 error[E0507]: cannot move out of a shared reference
  --> tests/arbitrary_precision.rs:77:47
   |
77 |         literal.parse::<i128>().map_err(|err| *err.kind()),
   |                                               ^^^^^^^^^^^ move occurs because value has type `IntErrorKind`, which does not implement the `Copy` trait
   |
help: consider cloning the value if the performance cost is acceptable
   |
77 -         literal.parse::<i128>().map_err(|err| *err.kind()),
77 +         literal.parse::<i128>().map_err(|err| err.kind().clone()),

test failure because that was just merged seemingly right before the current stable Rust. i will fix it, because this also applies to the compiler version that is currently in nixpkgs.

[sodiboo]

the actual tests are expected to fail when ran. as previously stated, this is due to a kdl-rs bug. but the CI did catch the fact that the tests did not compile on 1.88.0

[joshprk]

Hi, sorry for the wait. I'll take a look at this soon. I notice that the CI build didn't pass and you mentioned it, should I wait a bit longer or is it ready for review?

[sodiboo]

Yeah. This is ready for review. As stated, tests are failing due to a bug in kdl-rs which can't parse documents with arbitrary precision numbers (only output them), and my tests include round-trip tests to ensure they parse correctly. I looked manually at the test outputs; it seems correct.

No worries about the wait; i only really care about using this for nixpkgs, which doesn't support arbitrary precision anyways, so it's not like this is blocking anything. Take your time.

[joshprk]

After reviewing this, I think the best thing to do is annotate the clearly working test cases so we can compare the output text to something we verified in order to pass CI tests (since it would be unbecoming for a parsing tool to have failing CI).

It seems adding arbitrary precision to the upstream kdl-rs is non-trivial (or they can make a new KdlValue variant?), and we should instead make a tracking issue for it until they are able to address it.

Let me know if you have any concerns about annotating the arbitrary precision test cases with verified outputs that we can diff with the jsonkdl output. Otherwise, I'll co-author this PR to add the annotations. Thanks for sending in this PR!