feat(music_new): new interfaces for music, platform and API

[LucunJi]

给音乐，音乐平台和 API 设计了几个新的类。还没做完想先听听意见

---

Platform 负责通过搜索和歌单、专辑来找到音乐

MusicPiece 是音乐的实例。绝大部分属性都允许按需加载，减少不必要的延迟

PropertyRequestor 把 API 和用到的参数封装到了一起。如果同时从多个地方调用或者短时间内多次调用可以减少重复请求的数量（我不确定这个东西有没有必要）

---

其实 NeteaseMusic 除了媒体 URL 以外都可以快速批量获取。我这么写只是为了展示一下功能

[shuyangzhang]

今天我会先完成一下 在玩状态 和 qq音乐的封面解析，发布一下新的版本后合并这个pr

[LucunJi]

我把这个简化了一下，去掉了 PropertyRequestor，把需要立刻回显的名称和作者变成初始化参数。然后剩下的参数不如让人在实现的时候自己去写。

我之后有空的时候把单元测试也写一下再把代码推上来

[LucunJi]

解释一下新提交的更改：

音乐属性分三大类：

1. 基础信息比如音乐名称和艺术家：需要立刻回显给用户，而且内容不变，所以它们作为一般成员变量，要求创建对象时提供。
2. 封面链接：开始播放后收到 /list 指令才需要获取。所以是一个 getter 方法，意在允许异步和按需获取
3. 播放时间，媒体链接和是否可播放（版权信息）：必要但完全可以播放的时候按需获取。而且媒体链接可能是临时链接，所以也是 getter 方法，就地按需拉取。

我把 PropertyRequestor 删掉了，因为我发现上面后两类（第一类创建对象的时候就有了）一般都在很不同的阶段涉及到，同一个音乐对象一般不会同时索取两类属性，没什么异步上提升空间。唯一可能需要并行获取的是第三类中的三个属性，写代码的时候应该注意一下就好。

另外我不清楚 Platform 类怎么设计比较好。感觉在设计指令以后再设计平台会更好一点。我目前的想法是在每个平台类里放一个实现的操作的列表（__functionalities__）；或者用一个注册的设计模式，在注册平台的时候提供这么一个列表。然后命令那边的代码根据这个列表去给每一个指令生成出可用平台的列表…………

[shuyangzhang]

基础信息比如音乐名称和艺术家：需要立刻回显给用户，而且内容不变，所以它们作为一般成员变量，要求创建对象时提供。 封面链接：开始播放后收到 /list 指令才需要获取。所以是一个 getter 方法，意在允许异步和按需获取 播放时间，媒体链接和是否可播放（版权信息）：必要但完全可以播放的时候按需获取。而且媒体链接可能是临时链接，所以也是 getter 方法，就地按需拉取。

这个设计很赞，这个也是我一直想做的，这样搜索的体验会好很多