Implemented Keyword Substitution feature

@jrbl @jinpa 

![screen shot 2014-07-18 at 4 02 35 pm](https://cloud.githubusercontent.com/assets/3598201/3632888/a5fc93d8-0ecf-11e4-8154-69c818781e70.png)
![screen shot 2014-07-18 at 4 02 11 pm](https://cloud.githubusercontent.com/assets/3598201/3632889/a5fca044-0ecf-11e4-9238-d42c842bf8c3.png)

With this commit, instructors can include keywords in their bulk emails and
announcments that will be automatically substituted to the corresponding value
in the database. This commit introduces: %%USER_ID%% => anonymous_user_id and
%%USER_NAMR%% => user profile name.

This substitution in done by common/djangoapps/util/keyword_substitution.py. It
has a map between keywords and functions that will be called on the original
string (html document), and replace each keyword with the return value of the
function. In order to add more keyword substitutions, we can just add
"%%keywords%%" and their function mappings to the map in the future.

In the future, we can use this module to introduce keyword substitution feature
in other places.

** Since this feature deals with anonymous user ids, it's dependent on: 
https://github.com/edx/edx-platform/pull/4485
1. I was implementing the keyword substitution, and while running tests for it I found that the existing tests for bulk emails were breaking. So I looked into it and found out that course_ids containing non-ascii characters were causing the issue. Previously, bulk email tests and announcement tests never made calls to anonymous_user_id functions. 

2. Using .decode in is_ascii_string sort of a hack to find out if it contains characters with code > 128. I thought this was the pythonian way to handle this. Of course, there might be much better ways to implement this function. 

3. Anonymous User Ids are being instantiated lazily. That is, it is put in the database only when the user or the course instructor needs it. After being initialized once, it is not computed again and gets pulled from the database if we need it later. If we always encode to utf-8 from now, there will be a difference between anonymous user ids that will be computed from a specific user and course_id, and the anonymous user ids that already exists in the database. It might be fine to assume that this will always work (since they're never computed twice), I felt uncomfortable leaving it as is.