Various refactorings in the RPC system

[ElectreAAS]

This PR is a spin-off of #12473, containing only refactors. I tried to make each commit one single idea, independant of the others, but since they all modify the same files they're not git-independant.

1. Simple renaming of modules Rpc.Rpc_stuff -> Rpc.Stuff (but not filenames) Has been moved to #12585, is reverted in commit 6.
2. rpc_build.ml and bin/build.ml contained functions that were just thin wrappers around functionnalities in rpc_common. I removed said wrappers, so everyone has the same API.
3. Rpc.Common.run_via_rpc was also just a thin wrapper around two functions in the same module, it is deleted. wrap_build_outcome_exn didn't need to be a higher order function. The error handling is also unified across users of the API.
4. Having a nicer API means diagnostics.ml can just use it, no questions asked.
5. To do the same as in 4 to shutdown.ml, I needed to abstract the message kind (request or notification), and this is done via GADT two functions that are cleaner now

Feel free to suggest further PR splitting if necessary

[Alizter]

For 1, could you split it off into a separate PR. That should be easy to review. You can also rename the files there too. The rest I will need to think a bit longer about.

[shonfeder]

I think the core of this change suggestion points towards a useful cleanup. However, I am doubtful that introducing the new GADT is the most ergonomic route, so I've suggested a simpler approach, based on introducing a function for sending notifications.

In case you agree with my reasoning, you can see or must merge in mu suggestion from 0129cee

I am unsure whether removing the result that represents RPC message sending errors is wise, but I am not well situated to know whether the complexity of that explicit result value is worth the overhead, so will leave for you and others to decide.

[shonfeder]

I see we don't always use this when we call fire_*. Do you know why/when it is needed and where not? If so, that would be helpful info to add to the interface as documentation.

[ElectreAAS]

The new type should make the decision to use or not to use this function clearer:
Build_outcome_with_diagnostics.t -> unit
It just unwraps the sum type and prints errors and so. Don't use it if you want to print different stuff

[shonfeder]

How come we don't want to know whether the RPC resulted in error anymore? It seems to me that it would be useful, as I can imagine we could recover from sending requests in some cases.

[ElectreAAS]

It's a pragmatic change: every single user of this function had the exact same error handling code, so I just factored it in directly.

[ElectreAAS]

As a learning exercise, I'm using https://github.com/jj-vcs/jj to split this into several smaller PRs, thanks @Alizter :)

[shonfeder]

Is this ready for review, modulo resolving conflicts, or does the latest comment about playing with JJ indicate that you are planning to replace this with different PRs?

[Alizter]

@shonfeder There are quite a few unrelated changes in this PR, so @ElectreAAS said she would split them off slowly. I will mark this as draft until we are done with it in which case we can close.

[ElectreAAS]

This PR was split off into #12656, #12672, #12674, and #12675 which were merged, as well as #12585 which was abandonned. Closing as mainly completed :)