Remove ValueWithMetadata

[MichaReiser]

This might be too naive, but it's not clear to me what the benefit of ValueWithMetadata is.
It seems we can inline Value into ValueWithMetadata.

Closes #1053

Test plan

Verified that this reduces the struct memory usage (it's negligible over all but still)

master

TOTAL MEMORY USAGE: 164.69MB
    struct metadata = 11.23MB
    struct fields = 11.73MB
    memo metadata = 33.01MB
    memo fields = 108.72MB
QUERY COUNT: 68
STRUCT COUNT: 66

This PR

TOTAL MEMORY USAGE: 164.60MB
    struct metadata = 11.13MB
    struct fields = 11.72MB
    memo metadata = 33.01MB
    memo fields = 108.73MB
QUERY COUNT: 68
STRUCT COUNT: 66

When running ty on trio

[netlify]

👷 Deploy Preview for salsa-rs processing.

Name	Link
🔨 Latest commit	c4d3778
🔍 Latest deploy log	https://app.netlify.com/projects/salsa-rs/deploys/6970dbfcb64f2a0008c2b132

[codspeed-hq]

Merging this PR will not alter performance

✅ 13 untouched benchmarks

---

_{Comparing MichaReiser:remove-value-with-metadata (c4d3778) with master (5facdfd)}

[Veykril]

Yea I think this is actually fine now. We used to exclusively borrow the user supplied value in some codepaths which would cause aliasing or the metadata fields requiring this weird split. But after rebasing the PR a couple times it seems those issues resolved themselves now, I at least do not see places where we run risk of aliasing by removing this split again now

[Veykril]

I'd like to have @ibraheemdev double check that observation though just in case :)

[ibraheemdev]

This seems fine to me. I slightly prefer having the split and being able to use an UnsafeCell on the shared value part, but this is also fine (and avoids the need for repr(packed)).

[MichaReiser]

This seems fine to me. I slightly prefer having the split and being able to use an UnsafeCell on the shared value part, but this is also fine (and avoids the need for repr(packed)).

I wouldn't mind that as it at least makes clear why the split exists in the first place and gives us a chance to document what constraints must be upheld when reading or writing the field. Do we need the UnsafeCell for both the value and memos or would it be enough to wrap value?

[ibraheemdev]

I'm not sure, I haven't looked at the invariants closely. I think it's fine to merge this for the memory usage improvements and leave a TODO for later, it's not a huge deal.