异步 require 打包

[harttle]

目前提供了 __inlinePackage() 方法用于同步输出模块代码，inline package 后包内所有文件都可以按照模块方式引用。但 异步require的情况下会递归下载包内所有小文件，因此性能较差。需要考虑异步 require 场景下如何对每个包进行打包。以下是一些构想：

1. 不变更 apmjs 核心。在编译插件里实现。文件打包属于性能优化，不影响版本和依赖关系。因此安装后得到的结构不会发生任何变化，所有打包发生在编译时。
2. 原有的小文件继续存在，不强制打包。存在一些第三方库，并非所有代码都需要加载，只会加载其中一部分。这属于包内文件粒度的性能优化，要允许这种情况。
3. __AMD_CONFIG 只负责包的打包文件，包内的小文件从这项配置移除，解决 AMD Config 太大的问题。合理性在于：其他小文件属于精细的打包优化，可以要求手动配置。

[oott123]

// 1. require whole package asynchronously
require(['some-package']);
// 2. require a single file inside a package
require(['some-package/some-file'])

对于上述两种情况，是否说打包方案不覆盖其2，只覆盖1？

[harttle]

1. 主要解决异步 require APM 模块产生大量网络请求的问题，如下是搜索首页情况，结果页有同样的问题：
   
2. 解决 AMD_CONFIG 太大的问题。以下是结果页现状，下面还有一屏目测 > 20k
   

[harttle]

@oott123 对。合理性是这样考虑的：如果你要引用一个包的内部结构，那么你需要了解那个包的结构，所以让你去根据这个结构写inline配置也是合理的。

换句话说，如果包不是你写的，就不要引用里面的内部结构。

[harttle]

讨论纪要： @tayqassqan @oott123 @harttle 精简 AMD paths 配置的两种实现：

1. 所有文件加md5，只配置入口文件path。优点：稳定，可追溯，正确性不依赖于npm镜像。
2. 入口文件加版本号，所有文件不加md5。优点：所有内部文件都可以 require。

考虑到实现 2 不够稳定，且即使能require内部文件未提供内部文件打包也事实上不可用，没有解决更多问题。暂定采用实现 1。