[bug]: Floats ending in .0 converted to integers

[bgins]

Describe the bug

When converting a templated workflow to a Homestar workflow, values like 5.0 are converted integers like 5. In JavaScript, they are the same, but they are distinct when considered as WIT types.

To Reproduce

The Writing Functions blog post code generates some components that use float32 types. For example, the Rust sourced component has add and divide functions that implement a WIT with float32 types: https://github.com/everywhere-computer/writing-functions-blogpost-2024/blob/main/wit/math.wit.

Running the add workflow is probably the simplest test, but adapt the args to include a value like 5.0: https://github.com/everywhere-computer/writing-functions-blogpost-2024/blob/main/workflows/add.json.

This should fail with an error in the Homestar logs like:

ts=2024-03-04T21:25:08.909906Z level=error target=homestar_runtime::worker message="error in running task" subject=worker.run.task.err category=worker.run err="not able to run fn add for cid: bafyrmih3u5lcjxdxwcdd6e6srp4asihxvpepef7jmingens24dc3bi2qaa, in workflow bafyrmifpmy3dwkfasexrc4hq6tkfbh2plxh3dnmcjbfg6qtoi7z47sq4iy\n\nCaused by:\n    cannot execute wasm module: no compatible WIT type for Ipld structure: Integer(5)"

Expected behavior

Floats ending in .0 should be treated literally with the .0 preserved in the Homestar workflow.

Additional context

We did a quick experiment to see if we could avoid this issue with CBOR, but so far that has not been successful: https://github.com/bgins/cbor-float-test