feat(oxcaml): support parameter implementation

[shonfeder]

Closes #12085
Supersedes #12002

This PR is the second of a set of four PRs related to the introduction of Parameterized Libraries in Dune.

⚠️ This feature is only available with OxCaml until it is upstream to the compiler.

It contains multiples changes:

• It adds support for parameter in the implements field.
• It provides some tests to make sure the functionality act according to the specification. They are still guarded by the oxcaml variable.
• It extends the documentation with our case. More explanation about the feature will be addressed in future PRs, specific to the documentation.

TODO

• It needs the parameter to be merged first ✅
• Complete Refactor representation of library virtuality to represent disjoint logic in the type system #12253 and rebase on the merged changes
• Consider whether is_parameter should be removed (as per refactor: remove [Lib_info.is_parameter] #12298 (comment)).

[shonfeder]

Copying over the outstanding change requests from #12002

[shonfeder]

Thanks for the fixes, @art-w! I'll let you take this from here :D

IIUC, this is ready for review, so I will mark it as such.

[rgrinberg]

The Parameter case should be "assert false" I believe

[art-w]

Hm in the current implementation the Parameter case is useful, as a library that has an implements still get turned into a "vlib" which associates the library with the (virtual or parameter) lib it implements. I suppose we could avoid reusing parts of the virtual logic however, with a new sum type above. WDYT?

[rgrinberg]

I think it's confusing indeed then. Turning it into a sum type (or a record with a kind field) would clarify this.

[art-w]

I pushed a refactoring of Virtual_rules to distinguish between the three implements possibilities: no implements, implementing a virtual module or implementing a parameter. I think virtual_rules.ml could be further renamed to implements.ml, if the name "virtual" has too much connotation? :)

[rgrinberg]

Just finished a round of review.

[art-w]

Thanks for the quick review! I've marked the simpler issues as resolved by the last commit, but I've left open the ones where I would appreciate your input :)

[rgrinberg]

Could you remind where we add a dependency on the cmi of the parameter? Is it added a library dependency somewhere?

[art-w]

It looks like the dependency to the parameter is added by the pre-existing code for vlibs:

dune/src/dune_rules/lib.ml

Lines 1025 to 1034 in 07d0a93

	let* requires =
	Memo.return
	(let open Resolve.O in
	let* requires = requires in
	match implements with
	| None -> Resolve.return requires
	| Some impl ->
	let+ impl = impl in
	impl :: requires)
	in

[art-w]

This was moved (unchanged) to Vimpl.setup_copy_rules: https://github.com/ocaml/dune/pull/12392/files#diff-654c4360f33ebd2b51644332b9d26dcf9d2e39b1a2125ae4bc9f6400a7cc412cR74

[art-w]

This was also moved (unchanged) to Vimpl.make: https://github.com/ocaml/dune/pull/12392/files#diff-654c4360f33ebd2b51644332b9d26dcf9d2e39b1a2125ae4bc9f6400a7cc412cR20

[art-w]

I think this is ready for another review :) . I had to move large chunks of code in the last commit to clarify the implements field handling of virtual modules and library parameter, which makes this PR looks bigger than it really is -- I would be happy to submit that last commit as a follow-up PR if it's easier to review.