Expose individual server RPC endpoints for advanced users

[mbarbin]

In this PR, I propose that the generated service interface exposes the
individual RPC endpoints currently hidden. Here's an example of the change this
PR would make to a generated service:

@|-1,9 +1,19 ============================================================
 |  module Server : sig
 |    (** Produce a server implementation from handlers *)
 |    val make : 
 |      get:((key, unary, value_or_error, unary) Server.rpc -> 'handler) ->
 |      set:((keyval_pair, unary, unit_, unary) Server.rpc -> 'handler) ->
 |      delete:((key, unary, unit_or_error, unary) Server.rpc -> 'handler) ->
 |      listKeys:((unit_, unary, keys, unary) Server.rpc -> 'handler) ->
 |      unit -> 'handler Pbrt_services.Server.t
+|    
+|    (** The individual server stubs are only exposed for advanced users. Casual users should prefer accessing them through {!make}. *)
+|    
+|    val get : (key,unary,value_or_error,unary) Server.rpc
+|    
+|    val set : (keyval_pair,unary,unit_,unary) Server.rpc
+|    
+|    val delete : (key,unary,unit_or_error,unary) Server.rpc
+|    
+|    val listKeys : (unit_,unary,keys,unary) Server.rpc
 |  end

This idea originated from our discussion in #224

For a motivating example for this change, you can have a look at this pull request from a personal project.

• At present, I've maintained the "rpc_" prefix for names (e.g., "rpc_get"
  from the above example). However, I'm considering the potential for more
  consistency by using identical names for the client and server RPCs. Would
  there be any drawbacks to renaming the server endpoint to remove the "rpc_"
  prefix? Edit: now renamed to remove the prefix
• To be rebased once Proposal for automated generation of dune diff rules in examples/ #231 is merged

Thank you for your time and consideration!

[c-cube]

I'm open to this, it seems reasonable. The reason why there's rpc_… as a prefix is to make sure not to shadow make (which I do intend to keep!). However I suppose the codegen could just make sure that if a RPC endpoint is called "make" it gets renamed to make_ or something in that vein (both on the client and server sides).

[mbarbin]

Thank you for pointing out the potential issue of shadowing make, which I hadn't considered. I've updated the PR to adopt your suggested make_ naming convention and included a test case for this specific scenario.

The changes are now reflected in the examples/ expect-tests.

This PR is currently built on top of #231 . If #231 231 isn't considered for merging, please inform me and I'll adjust accordingly.

Thank you for your time and guidance!

[c-cube]

This looks good. Is there anything you want to add before I merge?

[mbarbin]

@c-cube Thank you for the review! I've tested the changes on my end with a preview package, and this behaves as I expected. Good to go from my perspective. Thank you!