Adjust plugin directory name for "wrongly" packaged zips.

[jrfnl]

This allows for instance for GitHub pre-packaged zips to be correctly installed and recognized.

Previously if you'd use the GitHub packaged zips - for instance: either master: https://github.com/lmartins/webipack-posts-widget/archive/master.zip or release based: https://github.com/lmartins/webipack-posts-widget/archive/v1.1.zip, you'd end up with an installed plugin, but with the plugin directory having a non-standard name webipack-posts-widget-master, cq webipack-posts-widget-1.1 which would cause TGMPA not to recognize it as installed.

Fixes #280, Fixes #283

[GaryJones]

Does there need to be a global $wp_filesystem, or is it already effectively done so by the $GLOBALS['wp_filesystem] on the previous line?

[jrfnl]

Yes and no. Good catch - I copied that line from the WP_Upgrader class and obviously missed that. Fixed.

[jrfnl]

Updated

[GaryJones]

Because the second part is the same in both messages, so makes for easier and more consistent translations.

Logical 👍

Once we split the files up, I'd like to look into having something along the lines of a TGMPA_Strings class which holds all of the strings, and could be accessed either statically or via dependency injection etc.

Merged.

[jrfnl]

Once we split the files up, I'd like to look into having something along the lines of a TGMPA_Strings class which holds all of the strings, and could be accessed either statically or via dependency injection etc.

We'll need to think about this carefully. Once we make the strings more context-agnostic, there should be little need for clients to overrule our strings.
Also it would be nightmarish to deal with plugin A overruling the strings, then theme B overruling the strings and us getting bug reports about error messages we don't recognize.