Fully separate Ice and Slice codec and IceRpc integrations

[bernardnormier]

Currently, the Ice and Slice IDLs (in .ice and .slice files), are implemented by the same assemblies, namely:

• ZeroC.Slice.Codec for encoding/decoding. Ice corresponds to SliceEncoding.Slice1 while Slice corresponds to SliceEncoding.Slice2
• IceRpc.Slice for the IceRpc integration

Using the same assemblies provide some opportunities for code reuse, such as:

• the encoding/decoding of integers and strings
• the logic for encoding/decoding sequences and dictionaries
• the helper code for proxies and dispatch methods (with some differences)

However, this sharing also increases complexity. It's all the more apparent now that we use different IDLs and compilers for Ice and Slice.

Proposal

• Move Ice and Slice support to separate assemblies
• Drop the terms Slice1 and Slice2
• Use "Ice" when talking about the Ice IDL saved in .ice files, and "Slice" when talking about the new Slice IDL introduced with IceRPC.

The resulting assemblies and namespaces are:

Assembly	Description
ZeroC.Slice.Codec	provides SliceEncoder and SliceDecoder
ZeroC.Ice.Codec	provides IceEncoder, IceDecoder, IceException, IceClass, …
IceRpc.Slice	provides SliceService and ISliceProxy
IceRpc.Slice.Generators	a source generator triggered by [SliceService]
IceRpc.Ice	provides IceService, IIceProxy in addition to IIceObject, Identity
IceRpc.Ice.Generators	a source generator triggered by [IceService]

This proposal has a few downsides:

• Changes the IceRPC Ice APIs (but we're already doing some changes for the 0.6.0 release)
• Some code duplication
• [SliceService] and [IceService] are incompatible, which means the same class cannot implement both Ice and Slice interfaces. However, we can't identify a clear use-case for such a service class.