[RFC]: backend指定通信后端

### 背景与目标描述 目前mindspore指定通信后端可以通过mindspore.communication.init()接口，传入backend_name为`hccl`、`mccl`、`nccl`实现，默认为`hccl`后端。但是在后端实现集合通信时，通信后端与硬件类型强耦合，在`Ascend`硬件下，创建通信组`mindspore.communication.create_group`接口会同时创建`mccl`和`hccl`后端的通信域且依赖主机侧建链（即cluster组网），需要仅创建`mccl`后端通信组时，需要指定创建的通信组以'mccl_'前缀命名。这种通信后端与硬件后端强耦合的方式易用性不高，且以硬编码来创建`mccl`后端通信组的方式不够优雅。  目前整体通信初始化以及创建通信组流程如上图，可以直观地发现collective（集合通信）与cluster（host组网）有着耦合的关系，并且创建通信组时必须要同时创建host通信组（一般为cpu后端）与device通信组（hccl、nccl后端）。 ### 设计思路  整体设计思路如上流程图，主要是引入了`backend`入参和新的`backend_list`来控制通信后端类型。 1. 将Backend类的实现由python挪到c++中。 2. 硬件类型（device_type）和通信后端（backend）之间是一对多的支持关系，比如说`ascend`硬件可以同时支持`MCCL`、`HCCL`、`LCCL`、`MPI`通信后端。在传入`backend`参数时会先校验该通信后端是否被所使用的硬件支持。 3. 通信初始化时不指定`backend_name`，默认`default_backend`为当前环境所支持的accelerator对应的通信后端；创建通信组时不指定`backend`，默认该通信组的`backend`与`default_backend`保持一致。若用户指定，则以用户行为为准。 4. 在初始化collective（集合通信）时，会基于`default_backend`看是否依赖于host达成一致（hccl通信组需要host侧通信能力去传播rootinfo信息）。如果依赖，有以下两种场景：1. 已经做过cluster组网，则复用scheduler和worker间的tcp通道；2.没有做cluster组网则自动创建一个全局TCPStore。 5. 创建通信组时，会依据`backend`创建通信组对象，而不是强绑定host侧和device侧通信组。比如在指定`backend="hccl"`，只会创建一个hccl后端通信组，不会同原流程去额外创建mccl后端通信组。在默认场景（不传入`backend`或`backend=None`）时，`backend`与`default_backend`一致，只会创建该类型通信组。 6. init时会初始化host相关硬件，但是不会创建host侧通信组；在create_group时，会依据backend来创建通信组，仅backend=="mccl"时只创建host侧通信组，其余场景仅创建对应device侧通信组；BroadUniqueID不再依赖于host侧通信组，而通过tcpstore以及collective内置get_rank API来实现。 7. `get_rank`等接口不再依赖于host侧通信组实现，相关数据结构以`{group_name: group_info}`的字典结构直接存储在collective_manager中。 ### 模块及接口设计 ``` def create_group(group, rank_ids, backend=None, options=None): """ Create a user collective communication group. Note: This method isn't supported in GPU and CPU versions of MindSpore. The size of rank_ids should be larger than 1, rank_ids should not have duplicate data. …