Solving 'unlock_at' edition bug for modules

Hi :)

A new bug to begin this wonderful week! ^^
This concerns the "unlock_at" date for modules and translations. I'm offering a pull request but I'm not sure it is the right way to solve this bug (but it does work). 

## :1234: Test plan

* Create a course, add a module,
* Change your language to whatever... (French for instance, as I use French most of the time),
* Edit the module and check the "unlock this module" checkbox, 
* Add an unlock at date (in the future) and save
* Edit again the module, you should see something like "this isn't a date" (or in French: Merci de choisir une date)
* If you edit something else and save (maybe after refreshing the page), the 'unlock at' date will disappear and thus the module won't unlock at the first inserted date! 

This is due to date translations & date formatting. French format (and I think other languages too) is not recognized when the date is saved, but as you fill in the form using the footer of the module, you fill it with the translation of the date and thus it creates the bug. 

## My fix

I added a new hidden span in the views where I insert the unformatted and untranslated date. Then I get it back from "context_modules.js" when we edit the module and fill in the form using that value instead of the one stored in the "unlock_at" span. 

I also get the untranslated value when we are comparing the date with the actual date for the show/hide "unlock details" information of the footer, because, again, the French translated date (and other translated dates) is not recognized by the Date.parse javascript function (it returns "null" so the test always fails). 

Let me know if I can improve my solution. :)

Kulgar. 
reinforces that the value from untranslated_unlock_at should be in iso8601, since $.datetimeString will be happy with that, but not necessarily with whatever the alternative gives