Clarify UseDevelopmentClustering and UseLocalhostClustering

[ReubenBond]

Fixes #4421

[ReubenBond]

I removed ClusterId & ServiceId parameters from the extension methods.

That means that there is a single way to specify ClusterId/ServiceId (ignoring legacy config).
The values will still default to "dev" when using UseLocalhostClustering, but only if no value was specified (and otherwise the startup would throw, once that validation is added).

In my opinion, this is cleaner. It means that users will have to manually specify the value when using UseDevelopmentClustering, but this seems alright to me.

UseDevelopmentClustering on the silo is paired with UseStaticClustering on the client. This is because there are other cases where the client might access the cluster using a well-known set of gateways. A static gateway list is fine for production use on the client. On the other hand, grain based membership is not fault tolerant and so it's usually not considered suitable for production.
UseLocalhostClustering on the silo is paired with UseLocalhostClustering on the client.

[ReubenBond]

@benjaminpetit we discussed this for about 40 mins the other day. I thought we had decided to add clusterId + serviceId parameters to UseLocalhostClustering only, however when I went to implement it I found that it didn't feel so good. I think we should take this as-is and instead add a helper for configuring those two in a separate PR. wdyt?

[benjaminpetit]

@ReubenBond let's discuss this live when you are available

[ReubenBond]

Ok, how does this look, @benjaminpetit?