Tezlink: remove tezlink impl record

What

Refacto to remove circular dependencies, and move as much as possible to the lib_dev/tezlink library.

depends on !17701 (merged)

Why

We want to isolate tezlink stuff depending on imports from the protocol (so types and services).

How

We can't have everything defined in Tezos_services. So types that are necessary in the backend need to be defined in Tezos_types, and Tezos_services needs to be removed from the dependencies of the service implementations.

We define a Tezlink_imports module that will be the top most dependency. It's should only contains import declaration and should be the only place where the protocol is mentionned.

Then we define a Tezlink_backend_sig and use the existing implementations to construct one in the Service_backend_sig.S. This allows us to cut dependencies between Tezos_service and the rest of the lib_dev. We can then move tezlink stuff in lib_dev/tezlink. We're left with the backend implementation in lib_dev next to the other backend implementations.

Alternatives:

• we could create a library declaring Durable_storage.READER, and have both lib_dev and tezlink depend from it, which would allow us to move the backend implementation in Tezlink. This would mean having backends defined in lib_dev and in tezlink though, and create a small library for stuff used in both (mostly Durable_storage and Durable_storage_path I think ?).
• we could split Tezos_service between components that need Evm_directory and Service_backend_sig.S (namely, the final functions in charge of registering the services, build_dir and such). That would require making the services and their types public, or providing individual functions to register each services, in tezlink. It doesn't prevent us from having from inserting our own module in Service_backend_sig.S in the end (see balance !17653 (merged)) so not sure what we gain. It would also mean that registering a service means importing it in tezlink, creating a registering function in tezlink, creating a backend in lib_dev, registering in lib_dev. And Tezos_service signature would be heavier, and verbose, complicating maintenance (and adding new stuff).

Manually testing the MR

It's refactoring, so green CI should be enough.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR