JIOPi v0.2类加载模型

JIOPi v0.2的类加载模型在延续JIOPi v0.1 POJO兼容的基础上，增加了对 JIOPi 蓝图 的支持。

JIOPi v0.1类加载模型参见 http://jiopi.iteye.com/blog/656895

蓝图的类加载规则：
JIOPi蓝图由以下Jar包组成：
当前蓝图的Jar包
依赖蓝图的Jar包
因此蓝图模块的类加载器必须将蓝图模块中的Jar进行分类，首先从当前蓝图的Jar包中加载类，如果加载不到，则应当调用依赖蓝图的Jar包所使用的蓝图模块的类加载器进行蓝图的加载，而不应该使用当前类加载器进行类的加载。
特殊加载逻辑：如果能够从当前蓝图的Jar包中加载到类，则应当检测ContextClassLoader中是否存在同名、同版本的蓝图，如果存在，则应当从ContextClassLoader中加载类，而不使用当前类加载器加载，从而保证实现模块的对象可以暴漏到ContextClassLoader加载的类中。

模块的类加载规则
模块由以下Jar包组成：
当前模块的实现类Jar包
当前模块的依赖蓝图Jar包
其他第三方类库Jar包
对于当前模块的实现类Jar包 和 其他第三方类库的Jar包中的类，由当前模块的类加载器进行加载，而模块所依赖的蓝图Jar中的类，则应该交由对应的蓝图的类加载器进行加载

蓝图的版本冲突
在大多数情况下，总是一个模块通过蓝图使用另一个模块，而这两个模块必然使用了同一个版本的蓝图，然而在下面这种情形下，会出现蓝图的版本冲突：
Aimpl-1.0.0.0模块 实现A1.0蓝图， 依赖 B-1.0蓝图，选择使用了 Bimpl-1.0.0.0的实现模块，Cimpl-1.0.0.0 依赖 A1.0，B-1.1，然而传递给Cimpl-1.0.0.0 的 B接口的实现类，有的是从 BNimpl-1.1.0.0 获得的，有的是从A1.0中获取的，而从A1.0中获取的确是B1.0的实现类，从而B蓝图的两个版本在 Cimpl-1.0.0.0中产生了版本冲突，当然，这个异常模型是不会出现在传统Java运行环境的，因为不可能出现一个类的两个版本，而这种情形却会出现在JIOPi的模块依赖模型中，并且JIOPi打算赋予Cimpl-1.0.0.0处理 B 蓝图不同版本的实现的能力，这个能力计划通过动态代理类来完成，从而避免强制类型转换异常。不过该规范没有被包含在JIOPi v0.2中，所以在使用JIOPi v0.2规范的实现容器时，要注意避免将同一蓝图的不同版本的实现类的对象在同一个模块中会合这种情形。