Hooking the logistration page into the new HTTP endpoint for email opt in

Updating the Login and Registration page to accept the email_opt_in parameter, which will set an organization-wide setting for receiving emails.

Related to the ECOM-525 story, sub task ECOM-680

@rlucioni @wedaly 
I've got a few questions here. 
- Since `course_id` and `optIn` are POST parameters, why not get them from `request.POST` instead of `request.DATA`?
- Speaking of getting parameters, wouldn't it be better to use `request.DATA.get(parameter)` instead of `request.DATA[parameter]`, so that you can check for `None` if one of those parameters isn't available?
- It kind of bothers me that the underscore-separated variable name (`course_id`) is being mixed with a camel-cased parameter name (`optIn`). Seems like we're using underscores in our other GET parameter names, so maybe it would be better to use `opt_in` instead of `optIn`.
- Speaking of variable names, I see there's another variable here named `optin`. Maybe this could also be named `opt_in`, for consistency with the parameter name.
- Finally, wouldn't it be better to set `optin` to `True` if the opt-in GET parameter is equal to "true", and set it to `False` otherwise? That is, `optin = request.DATA['optIn'].lower() == 'true' `. This is the assumption I made in the student views. It doesn't seem like we should opt someone in to receiving email unless value of the parameter is exactly what we expect (i.e., `true`). If you use `request.DATA.get(parameter)` instead of `request.DATA[parameter]`, you can also use this equality check to set `optin` to `False` if the opt-in GET parameter is `None`.

In summary, I'd change this line to look like this:
```python
opt_in = request.POST.get('opt_in').lower() == 'true'
```
Phew!