schema_list should support sub-folders.

[shenlebantongying]

Current behavior

To install new schema, user have to put all schemas in one folder like

config/
 |- new_pinyin.scheme.yaml
 |- new_pinyin.dict.yaml
 |- default.custom.yaml

and in default.custom.yaml

schema_list:
  - schema: new_pinyin

Take a look at install instruction of one of the most popular schema:
https://github.com/KyleBing/rime-wubi86-jidian#%E5%9B%9B%E5%AE%89%E8%A3%85

It's way too many steps, and update isn't elegant (do everything again).

Expected change (as extra behavior)

Let users put schemas in separate folders like

config/
 |- new_pinyin/
        |- any_name.scheme.yaml
        |- any_name.new_pinyin.dict.yaml
        |- README.md of new_pinyin
        |- other files...
 |- default.custom.yaml

and specify like this

schema_list:
  - schema: new_pinyin/any_name 

Rational

• Installation of a new schema become as simple as git clone a-repo (or a copypasta curl command) without the need to manually copy files
• User can update them easily with git submodules or just git pull.
• Keep the README.md within the schema's folder for extra reference.
• Removing a schema become as simple as delete the folder rather than individual files.
• Schema author can update within a git repo (-> the folder) rather than moving file around.

! The need for overengineered tools like /plum/ is eliminated. Just reuse git or curl.
! This simple change also related to #336

[lotem]

Interesting idea.
I can foresee that once implemented, this could simplify the installation process for tech savvy person; yet I don't think it'll completely obsolete the effort of #336, because the ultimate goal is to simplify the configuration workflow for a larger user audience (though this goal is far from achieved today). Another important functionality of a configuration tool is patching a configuration file programmatically - content of patches from different authors/repos are merged other than one overwriting another; this is even more difficult than the file-copying part, and remains to be solved.

IMHO the idea is worth exploring because the suggested directory layout has the potential of supporting more complex configuration and faciliating code sharing.

This change isn't as trivial as "sub-directory support in the path-finding of schema files". We need to answer a series of follow-up questions: where to look for a translator/dictionary or other files referenced in a schema file? We certainly don't expect the dictionary parameter to change if the repo is cloned to a different path; what if the schema refer to a dictionary from another repo, how to specify the dictionary without knowing the upper-level directory layout?
The source YAML files having adopted a tree-like directory structure, then how to implement the filesystem layout in the correponding build directory?

While files may be structured like so, it may not be a good idea to explicitly write the directory in the configuration.
To make sure pieces of code work together as before as their code repos freely relocate, we need to do some bookkeeping in the IME program: like registering a package for at least knowing how to find the resources it provides.

Hopefully I made it obvious that it leads to a philosophy change in how to use the YAML source files: configuration packages are drop-in; the configuration from different sources naturally work together without being modified - this require substantial change in librime because the program was not planned to support such complex use-cases.

The current configuration tools work as follows:
The downloaded recipes are materials for creating a working configuration, and they are copied or patched to a "staging area" that is the user config directory. Because the operations are potentially destructive (for example editing a patch in a .custom.yaml file), if the user wants to make some changes to the configuration they should modify the list of recipes to use and recreate the "staging area" using the downloaded raw materials.

To support "drop-in" configuration, a recipe should apply to the user's config in a non-destructive way. If we put aside the the fact that Rime is making copies of the information from the downloaded YAML repos before using it, I could try to convince you that the current tooling is triving to work in the way you proposed:
If you look into the plum/package directory, you find the downloaded YAML repos lay out like the suggested directory structure; files in these repos are not modified because the destructive operation happens in the "staging area" - the Rime user directory. Then, let's take plum/package directory as our new "Rime user config" and regard what happens in the "staging area" as Rime building config data internally, then we achieved "drop-in" configuration by virtually wrapping plum and Rime proper into a desired implementation. Patching and file copying that happen in the wrapper is merely an implementation detail and could further be optimized away by refactoring plum into Rime's deployment process.