generalize the functionality a bit more

I'm concerned this library is trying to do too much. In it's current state, I kinda doubt it would see much adoption outside of `ava-codemods`. I see two possible directions you could take this thing:
1. A suite of helper utilities others will use to ship their own tool.
2. A pluggable platform, where libraries can publish upgrade configs, and we supply one unified CLI for processing their published codemods. Plugins could be installed like `npm i -g lib-upgrader-plugin-ava`.

I think `1` will be easier to implement, and more likely to be adopted. Pulling off `2` will be hard. As you have already pointed out in Issue #2, there might be more to upgrading between versions than just bumping dependencies and running a set of codemods. Sometimes, this might mean developing your own set of prompts (like "Hey, we split this feature almost nobody uses into it's own module. Do you actually need it?"). Building this level of flexibility into a pluggable system is difficult.

I think it would be wise to leave a good bit of what's in the main export of `index.js` in `ava-codemods`, and instead make users supply a lot of that glue code themselves. Instead we should just supply a series of utility functions:
1. Methods for sorting a set of objects based on a property that contains a semver string.
2. Selecting a range of objects given `from` and `to` semver targets.
3. Some set of git status safety checks (like `is-get-clean`).
4. A method of making sure your codemod is up to date. Could be as simple as pointing implementors to `update-notifier`, or we could get more strict (i.e. "Upgrading to AVA 0.16 requires ava-codemods X.XX or higher). We could add a custom field to AVA's `package.json` that specified which codemod version was required.
5. A method (as discussed in #1) for querying `npm` for the latest and greatest version of a given library, and updating package.json. We could help do nice things like, like matching the range type (`^` or `~`) when bumping.
6. A method of listing versions available on `npm` that filtered out stuff you don't care about (i.e. don't show patch updates or deprecated versions).

Much of the above should all be their own modules, keeping things small and focused. I think you have already nailed `1` and `2`, and I think you should publish a small module that does just those two things.

Maybe someday, when codemods are ubiquitous and the defacto way to ship breaking changes, we can tackle a fully pluggable ecosystem. But for now, I vote we keep things simple.

Start by reading the current main export in index.js and the discussion referenced in Issue #2. This issue proposes several possible utility modules and a broader platform, but does not select a concrete scope or define acceptance criteria; agreement on the direction is needed before implementation can begin.

Written by the indexing model from the issue text.