Fail if we download the incorrect version of Gravity Forms

[mcaskill]

Checklist

• [x] I've read the Contributing page.
• [x] No issue.
• [ ] My code is tested.
• [x] My code follows the WordPress code style.
• [ ] My code has proper inline documentation.

Description

Follow-up to #47 and fork of #58.

Depends on #58 being merged first.

Use Semver to check main and latest versions.

Prioritize main version (download_url) over latest version (download_url_latest) since most people will only specify MAJOR.MINOR.PATCH as opposed to Gravity Forms PARADIGM.MAJOR.MINOR.PATCH. This also prevents "contamination" of a cache key for a "main version" with the contents of the "latest version".

Improved GravityForms to check if download version matches the package's version with support for either available download: the "main version" (download_url) or the "latest version" (download_url_latest). For example:

• version (main): 2.7.2 (PARADIGM.MAJOR.MINOR)
• version_latest: 2.7.2.1 (PARADIGM.MAJOR.MINOR.PATCH)

By checking both and distinguishing between them, this prevents "contamination" of cache key for a "main version" with the contents of the "latest version".

For example, currently if a project requires Gravity Forms 2.7.2 (which is used as the cache key):

• User A installs the project and the Composer plugin downloads 2.7.2.1.
• User B installs the project the next day and the Composer plugin downloads 2.7.2.2.

Now you have two users with differing versions but using the same cache key.

How has this been tested?

I'm testing this on a client project that uses Gravity Forms.