Support prereleases about pub_updater

[renancaraujo]

The pub API has two potential sources for fetching the "latest" version on the packages endpoint:

• The "latest" field on the packages, which will take the latest stable release, if none, the latest pre-release
• A list with all versions, assuming that the list is ordered chronologically.

Some facts about this:

• We cant trust the chronological order of release to define as being "up to date", especially when it is about pre-releases. One may have two pre-released tracks for the same version with interlacing release dates. Ex:

- 0.2.0-nicefeature.1 released Monday
- 0.2.0-awesomefeature.1 released Tuesday
- 0.2.0-nicefeature.2 released Wednesday

You wouldn't like to have people updating from awesomefeature.1 to nicefeature.2 since they may preview different features.

• We cant trust pub-semver's compareTo to define the order of pre-releases. Since 0.2.0-awesomefeature.1 is considered precedent of 0.2.0-nicefeature.1 because of alphabetical order.

Proposal:

Add a boolean flag to isUpToDate to always return true if the running version is a pre-release since there is no safe way to define compare pre-releases.

[renancaraujo]

This affects specifically cases where there is a stable release for that package.
For packages with only pre-releases, this won't happen.

The fix for this issue should maintain the behavior on the latter but fix the false positive on the former.

[blaugold]

@renancaraujo Thanks for working on this! An approach to still support upgrading pre-release versions could be to allow users to pass in a sorting function for pre-release versions. WDYT?