统一处理Weex库和Rax库的一些逻辑

历史描述

• 之所以命名要带Weex字眼，是因为Weex-cli生成的工程，loader会自动排除掉名字包含'weex'的库，使其源码发布也能被babel编译。
• 之所以名字要带Rax字眼，也是出于同样目的，方便源码发布保持底层依赖的框架环境一致。但是Rax库不会排除名称包含'rax'的npm包，因此需要使用rax-scripts-dt暂时替代rax-scripts。rax-scripts-dt做了node_module路径排除的事。

工程结构介绍

• plugins 为了保持双端统一，有些差异化可以按照其功能上的种类进行统一实现&管理
  • plugin 一个插件的积累，实现插件要继承这个，并实现里面定义的方法
  • impl 所有plugin的实现
    • ability 限定一些能力，有些能力iOS和Android都比较强（如坐标轴支持两个以上）但是对用户而言使用成本和答疑成本较高，因此做了限定只支持两个轴等等类似的作用
    • default iOS有一些默认属性，android也有默认属性，两端属性不尽相同，而且对于android端而言，解析weex端传递过来的属性解析之后如果没传变为null，会导致抛出异常而不会走默认表现。因此被要求将所有配置项一并补全，目前功能上是对已有的object里的key进行补全。如果object不存在则不会自动补（如array为空，里面不会生成object元素）。这里遵循的配置规则看对应目录下的config.js里的注释说明
    • polar-empty-point 专门用来解决android端极坐标图，对于没有数据时候的错误展示。正常android是会crash，通过这个进行修复
    • polar 极坐标的plugin，通常会给indicator描述（因为层级比较深，并且和数据相关，default不能满足功能）加上默认值
    • typo 有些内容是早期版本配置项的api制定失误导致的，为了保证兼容性，在api变更之后仍然会复制到旧的key上一份儿。支持多层级下同层内的键值替换
    • xy-axis 坐标轴，iOS端的坐标轴会根据数据是否依赖而自动生成对应的轴的配置，android端则需要手动指定。因为又是和数据相关的，default并不能满足这样的需求。
    • xy-point 数据层的差异，android除了scatter接受[x[], y[]]的数据之外只接受[y[]]，iOS全部接受[x[], y[]]，因此需要把这块儿的差异抹平，iOS自动在补齐x[]，scatter图表在iOS处则需要特殊处理，保持用户传递的原值。
• polyfill weex的vue框架和rax框架某些地方会有差异，主要是提供一下抹平差异的工具方法，具体内容见代码注释
• theme 有些颜色上的补全，参考这里面的值
• util 一些辅助工具方法见代码注释
• acechart-common-data-converter 用于统一处理一些东西，一般不用动
• acechart-android-data-converter 用于在common-data-converter之后处理android端的内容，一般不用动
• acechart-ios-data-converter 用于在common-data-converter之后处理iOS端的内容，一般不用动
• acechart-web-data-converter 用于在common-data-converter之后处理web端的内容，一般不用动
• plugins 导出所有要执行的plugin, 其顺序是有影响的。注意不要轻易调整