Better separation of binary and library

[Andriamanitra]

refactoring to get the library ready for 1.0 release (#28)

WIP

[Andriamanitra]

edit: this is done now

Should we move OutputStyle and print_headers, print_statement, print_testcases, print_reverse_mode functions out of the library? They're very specific to the CLI and I don't think it's a good idea to commit to keeping them stable (we don't want to break the clashlib API when we tweak how the clashes are printed in the CLI tool).

[Andriamanitra]

Are there any more parts of main.rs that would make sense to provide as part of the clashlib API?

[Andriamanitra]

What should the public API of solution look like? The current API is really weird (and basically undocumented). Maybe we should just hide the entire module until we can figure out a better API?

[Andriamanitra]

re: @ellnix (from #71)

I suggest

• Moving App to lib
• Moving all the helper functions (functions that do not have a corresponding command) into App
• Removing the functions that have commands corresponding to them from App and just having them as regular functions in main.rs (or as part of a Cli type)
• Making the App constructor to take a single package_name parameter: let app = App::new("dev.CoCtus.coctus");

This would then separate the responsibility between calling the commands and the helper functions which we could use in tests. It would also prepare for #61 by allowing configuration to be stored in App and be used by users of the lib.

I've given this some thought and I think that it would be better to expose a simpler API that is completely agnostic of the coctus CLI tool and its data/config (that means keeping App private as its only purpose is to hold references to the configuration directories). Users of the library should have the choice of using their own config/data if they want to be independent of coctus the command line tool.

There are probably some methods in App that do "too much" though. Ideally they would follow this recipe (limiting I/O to the edges of the app):

1. Doing I/O (reading args, environment variables and files)
2. Passing the data forward to pure, easy-to-test functions (which we may want to expose in lib)
3. Doing I/O (printing the output / errors)