Ahead of #63.

This PR splits the 17 modules into separate small crates like @ngtkana's ac-adapter-rs.

It aims to make development of "bundlers" that works with ac-library-rs like this easier.

https://judge.yosupo.jp/submission/28576

Benefits

1. We can easily, and precisely, list bin → lib (→ lib) dependencies by using cargo-udeps. We don't even need to parse source code of the bin by ourselves to find "dependencies".

Drawbacks

1. With this plan, we would write "extern crate" usages as follwing. "Bundlers" would have to process this format. Also I'm not sure it is the best way to expand multiple crates.

   extern crate __acl_foo as foo; // refer to this!

   ↓ some tool (including expand.py)

   /*extern crate __acl_foo as foo;*/use crate::acl_foo as foo; // refer to this!

2. This kind of crate is very incompatible with @kuretchi's cargo-simple-bundler. If we seriously follow the plan, we force cargo-simple-bundler to do:

   • Support 1. or something.
   • Consider lib_a::foo → lib_b (or lib_b::bar) dependencies.
   • Change the interface so that it can process multiple lib crates.
   • etc., etc.

3. We would have to publish 18 crates.

   • We may publish documentaion on github.io instead of docs.rs.

4. This change may interfere with manual copy-and-paste.

   • But we already provide expand.py. It would continue working, and it is easier to use than copy-and-pasting by hand.