Refactor client/daemon architecture

Goals:
- [x] Only one process ever accesses the database
- [x] All commands are proxied to a running daemon (currently only execute is)
- [x] Client processes don't load/validate config
- [x] Client processes don't load plugins
- [x] ~~User plugins load from config directory rather than hard coded to ~/.flexget/plugins~~ (can be added later if desired)

EDIT: (explanation of final code below, this isn't quite how it worked out) I'm not exactly sure how appropriate the Manager class is anymore for always being the main entry point. I'm thinking that client processes should not even instantiate a Manager. Here's my current thoughts on what happens when calling flexget executable:
- Run parse_known_args with an argparser that only has the base options configured. (have to be careful of this stealing options from command when there are similarly named options)
- Find the specified config directory
- Start up logging
- Check for lock file

At this point, execution will split, based on whether there is a running daemon. (determined by checking lock file)

Case 1: (no lock file found)
- Instantiate a Manager class
- Manager will now be responsible for loading plugins
- Call some sort of `run_command` method of manager, where we pass the extra options not parsed in initial argparse pass

Case 2: (active lock file found, it isn't a daemon)
- Just quit with an error, you can't start 2 flexget processes at once.
(Or should commands be able to be proxied to a running flexget which isn't a daemon? e.g. user (or cron) runs `flexget execute` then before it's finished runs `flexget series list`, or another execute command)

Case 3: (active lock file found, it's a daemon)
- Some sort of ipc method that proxies to the daemon Manager `run_command` method with our extra cli arguments
- All logs and stdout resulting from `run_command` get proxied back from daemon and displayed to client process

EDIT: Here's how the code is actually working now.
- Manager uses cli parser before plugin load to get initial options.
- Instantiating manager doesn't load config/database anymore. It just finds config file so that we know where to look for lock file, and where to start logging.
- `start` method of manager checks for existing running process, if found sends the cli args there to be parsed and executed.
- `start` method obtains lock, runs `initialize` method of manager which loads plugins, loads/validates config, and sets up database, then calls `handle_cli` command to run the cli args locally.

If we go with this plan, here are some things that need to happen:
- [x] ~~Separate lock file code from Manager~~
- [x] ~~Separate config finding code from Manager~~
- [x] Move plugin loading into manager initialization
- [x] Add run_command method to Manager, which takes the cli options (this includes the command and its options)
- [x] Convert execute method of IPCClient to be a generic run_command
- [x] --cron option affects logging startup, so really should be root level option

@paranoidi Any thoughts are appreciated, just trying to dump my ideas here now to get feedback.