Support "UI process" as a plug-in management process

[jiongxuan]

支持以“UI进程”作为“插件管理”的进程

该模式适用于“App启动时只有一个进程”，或者应用“不需要常驻进程”的情况（当然，开启此模式仍然支持“多进程坑位”的处理）。

此模式也可降低初始化启动RePlugin的时间（无需启动另一进程），然而，一旦UI进程退出，则再次启动的时间会比“常驻进程”模式的要慢一些（因为需要重新初始化、读取插件信息等）。
具体以后会写WiKi来做详述。

适用于此模式的360应用目前有：花椒相机、360借条、360你财富等不需要后台服务的应用
适用于“常驻进程”模式（原）的应用有：360手机卫士、360手机助手、360清理大师等，对后台服务有一定需求应用

[wangfuda]

这里是否相应的调整下，避免歧义：
should be ? : // 常驻进程(或UI进程)Provider

[wangfuda]

场景：
用户设置了persistentEnable = true
用户设置了persistentName = applicationID
结果：
初始化时，既不会执行initForClient()也不会执行PMF.sPluginMgr.attach()，导致该进程信息未注册到“插件管理进程”中

建议：
1.为了避免用户将常驻进程名设置为了applicationID而因此初始化不完整，是否可以在这里增加判断当前进程名不等于applicationID，进而保证在这种特殊情况下，流程仍能正确执行。

注：仅供参考，毕竟要权衡下，为了这一错误理解常驻进程命名的编码行为做兼容是否值得。

[wangfuda]

请忽略这个建议，代码里还是不要做这种兼容。

[jiongxuan]

嗯，这个发现非常的好，这也确实是一个改进点。

我觉得可以这么搞：如果persistentName配置成和包名一样，则默认将persistentEnable改为false（在Gradle生成期搞），同时出一个警告。这样就“天然的”做了容错处理。

当然，这块儿我还会加个注释来说明下，同时在IPC的判断条件中也加上类似的容错处理，这样可确保流程的完整性。

[wangfuda]

编译期提示警告，这个真心好