Only changed strings should be saved to DB

[jbphet]

While working on #208, I noticed that all non-zero-length strings are being saved to the DB when the user presses the "Save" button on the translation page, as opposed to just saving those strings that were changed by the user. In most cases, this doesn't cause any problems, but I can envision a scenario where one translator starts a translation, presses the "Save" button (intending to return to it later), then another user finishes a translation for the same sim, then the first users resumes their work. In this case, strings changed by the 2nd translator could accidentally be overwritten with previous values that the 1st translator hadn't changed. This situation could be avoided, at least mostly, by saving only strings that a translator had actually changed.

I'm tempted to fix this now while I'm working on the DB-related code, but I think I should instead concentrate on other, higher priority issues such as a11y support, so I'm documenting this as something to potentially address in the future. I don't think it has ever come up as a problem for two main reasons:

• We generally have just one translator working on most sims.
• I don't think the translators use the "Save" (for later) functionality very much. I suspect that they usually just finish a translation and submit it.

I'm going to mark this as deferred and leave it unassigned, but if we ever initiate an effort to make Rosetta more robust when being used by multiple translators, this should be considered.

[liammulh]

In Rosetta 2.0, we use MongoDB, and we just save the whole translation form data to the database, and we are fine with this.