Hotfix - reduce number of Studio mongo calls

There was a large performance degradation seen today on Studio which a number of folks have been investigating. TL;DR I have a hotfix which Nimisha and I believe to have resolved the issue.

The issue was seen on unit pages (note: not the course outline page as was originally though) where the number of Mongo calls increased substantially. A typical example can be seen on New Relic, where a single unit page caused over 900 Mongo queries to be executed:

https://rpm.newrelic.com/accounts/88178/key_transactions/9482/x_rays/1073/profiles

Nimisha, Cale and Don investigated today and discovered that the problem was with the number of calls being made to has_changes. As part of bulk publishing, the logic was changed where has_changes was called for every xblock being rendered, rather than only for units. This was part of this PR:

https://github.com/edx/edx-platform/pull/4750

This change was performance tested for the course outline page, but unfortunately it wasn't recognized that it would actually have a larger impact on the unit page so it wasn't tested there.

Don implemented caching of has_changes so that the value for an xblock and all of its descendants are only computed once. This helped somewhat but not enough for a subtle reason. Nimisha and I investigated tonight and realized what the problem was. The logic for the unit page computes information for the unit page first, then recurses up to the parent to get its information, and continues all the way up to the course. This means that the caches are not available as the logic goes up the tree.

I implemented a simple one line change on top of Don's fix that first calls has_changes on the course module itself, so that the entire tree of has_changes methods are called once and only once. This brought the number of Mongo calls back to reasonable levels based on tests that Cale wrote.

Here are the results for Cale's tests with different branching levels. For example, a branching level of 3 tests with 3 sections, each of which has 3 subsections each of which has 3 verticals each of which has 3 problems. As you can see, the release branch numbers increase in some sort of exponential way as the course increases in size, but with the hotfix they are linear. This demonstrates that Don's caching is effective in avoiding unnecessary Mongo queries.

```
+=================+===========================================================+
|                 |                        MONGO CALLS                        |
+=================+===========================================================+
| Branching level | Release branch | Release w/ Don's fix | Release w/ hotfix |
+=================+================+=======================+==================+
|    1            |        42      |         31            |       36         |
|    2            |       122      |         78            |       39         |
|    3            |       360      |        251            |       42         |
+=================+================+=======================+===================+
```
We probably need to add cache invalidation logic into the update_item method. I'd have to think a bit how to do that cleanly, and it may not be necessary b/c of the call flow as the cache only lasts for one request, but you may want to test whether making an edit on a clean (no has_changes) component properly marks the ancestors as dirty.