Release process/version changes

Proposed change would move from having version numbers created only during release task, to storing them directly in source. The automated release process could then be updated to bump and commit version numbers.

Motivation:
- One central place for version number, Jenkins is no longer keeping track of part of it
- Rolling over to new major version is as easy as changing version number to e.g. 1.3.0.dev, without resetting jenkins revision count.
- RTD can see version numbers and allow browsing by version
- Git users get meaningful version numbers
- Git tag now has exact release source code including version
- paver tasks simplified, separated out release management from actually building one
- would easily allow setting up alternate releases, 

Cons:
- Extra 2 commits per release
- more automated commiting and merging by jenkins (this shouldn't be a big deal, because nothing will be pushed back to github that isn't a fast forward)

- version number is now stored in `_version.py`. This is so that it can be accessed easily by setup.py (without importing flexget), and to make it easier to automatedly change and commit the version number without conflicts.
- New paver task `increment_version`. Without `--dev`: If current version is dev, strip the dev, else increment minor version number. With `--dev` if current version is dev, increment dev number (e.g. dev3), else increment the minor version number and add dev tag.
- New paver task `version` to ease getting version number from jenkins
- release paver task could really be removed now, it's just sdist with tests

New release process (whether by hand or via jenkins job):
- Tests on develop should be passing first
- Checkout develop
- Run `paver increment_version` to get new release version number
- Run `paver sdist` to create new release
- Commit changes to _version.py
- Make a tag for new release number
- Merge changes into master
- (on develop again) Run `paver increment_version --dev` to increment version number and add .dev again
- Commit changes to _version.py again
- Push new tag, develop and master branches back to github.

I tested the whole process on my fork and everything went well.