Unify translation checks when saving and skip whitespace only strings

On closer investigation, I'm not exactly sure how these translations/suggestions are getting saved to the database. I'll need to do some more research.

Ok I figured it out. If you enter a suggestion or translation (as anonymous or not) as just a bunch of new lines (select the textarea, hit enter a couple of types and don't type any other keys), they get saved as empty translation strings. Should we just be running a trim() on the textarea data before saving?

Hm, yeah, we should do a trim.

Ok, this was obviously a bit more complex then just running a trim(). We should not trim() blindly, since we also check for duplicates, and some strings have leading or trailing whitespace for various reasons. So we have a trim() function, which trims the target and applies the same leading and trailing whitespace as on the source string. But we should first check whether we have a translation string at all, so we don't bother with all these fancy things. Finally, the .po file imports and the remote string submissions should use the same rules as well, so we have a consistent entry interface.

After all this is how I've implemented this:

- moved the trimming out of the save function; it is also required to do before the duplicate check, so we should do it at all times before saving
- ensured we have a $sid and $source in all three cases we save strings
- ensured we always check for non-empty trim()-ed translation first
- then apply the source based leading/trailing whitespace
- then check for duplicate translation/suggestion
- ONLY then save the string if all passed

I took the opportunity to clean up the remote submission checks a bit, so we have a list of similarly formatted checks, instead of some being positive while others being negated. Also, made some of the error messages more verbose, where we've seen localize.drupal.org bugs noting issues. Eg. "Wrong parameters or signature." became "Wrong parameters or signature. Did you set your user API key on your user account page?"

I've tested this with the automated tests in the module as well as manual translation entry, .po file imports crafted for the issue at hand and remote submissions with two Drupal sites running on my machine. Found a few bugs in my original code on the way and now everything seems to work fine, so I'll commit this and deploy on localize.drupal.org.

Retitle.

Automatically closed -- issue fixed for 2 weeks with no activity.