feat: Update derive field overwrite support

[Veykril]

I believe this should allow reducing the need for coherence dependencies like

salsa/Cargo.toml

Lines 29 to 30 in ceb9b08

	# Stuff we want Update impls for by default
	compact_str = { version = "0.8", optional = true }

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	398e134
🔍 Latest deploy log	https://app.netlify.com/sites/salsa-rs/deploys/67cbf43f57e03a000838edc3

[codspeed-hq]

CodSpeed Performance Report

Merging #747 will not alter performance

_{Comparing Veykril:veykril/push-xzzvvzlxwmvo (398e134) with master (dbb0e5f)}

Summary

✅ 11 untouched benchmarks

[Veykril]

Actually, @MichaReiser I believe this could be a viable alternative for the Update requirement issue. You'd define a helper function fn(_: *mut Map<CompactStr, ...>, Map<CompactStr, ...>) -> bool and then just reference that in the places where you need it here. That avoids the coherence problems with third-party crate types while also not requiring a wrapper newtype that implements Update for the given foreign type.

[MichaReiser]

Yeah, it does reduce the urgency for having Update impls in salsa but I think it's still less ergonomic because it now requires a change at every use.

[Veykril]

Well, I don't see better ways to avoid this. We obivously can't add every crate out there as a dependency to salsa just to add the Update impls for the types.

[Veykril]

Either way I believe this to be a nice addition to the derive. Improved the diagnostics a bit so this is ready now

[MichaReiser]

Either way I believe this to be a nice addition to the derive. Improved the diagnostics a bit so this is ready now

I agree with this. It definitely raises the bar for which Crate Salsa should provide Update implementations. But it comes at an ergonomics cost, which is why we'd probably want to keep providing Update implementations for some popular crates.