Merge+Diff follow-ups

[sipsma]

Tracking followups from comments on merge+diff here. Can instead break this into separate issues for each one if preferred.

Short-term followups:

• [x] Update progress for merge and diff. Draft PR for merge here.
• [x] Update inline cache for merge and diff. Draft PR here.
• [x] Documentation updates, with format as described here.
• [ ] Unlazy merge+diff refs right away if they will be needed for a solve. Comment here.
• [ ] Support returning direct nil from solver op execs. Comment here.

Performance followups:

• [ ] Deduplicate equivalent merges
• [ ] Deduplicate equivalent diffs
• [ ] Re-use submerges when possible, i.e. if Merge(a,b) already exists, use it to speed up creation of Merge(a,b,c)
• [ ] Normalize merges to their simplest form, i.e. Merge(a,b,a) is logically equivalent to the simpler Merge(b,a)
• [ ] Don't finalize input refs when they are created by llb.Local. Comment here.

Longer-term followups:

• Cache diff metadata and use it to apply diffs instead of always running the double-walking or overlay differ every time. Comment here
• Deduplicate code between diffApply and the containerd/continuity appliers+differs. Comment here.

[sipsma]

@tonistiigi I will prioritize the short-term follow-ups, especially progress+inline cache+docs since I'm assuming they are hard requirements for a v0.10. Let me know what feelings you have on the priority of the others, especially which ones you consider blocking for the next release.

[tonistiigi]

Support returning direct nil from solver op execs.

I think this is not needed unless you see benefits. It's somewhat nice to validate the return array length like you described in that response.

Don't finalize input refs when they are created by llb.Local

Just a thought as well. I think we need to first understand if there are cases where it is beneficial.

I think the blockers on my side are the progress(I think we need different approach than the draft pr), inline cache(draft PR mostly looks good) and Moby vendor.

I'll try to pick up the work on the Dockerfile side. At least for mergeop, not sure if we are ready for diffop yet. Having some optimizations for copy as like discussed would be nice as well(storing diff metadata on fileop and using direct hardlinks from overlay lowers for copy when possible).