Implemented Bulksettings page & Tests

From Jane's Story: 

@jinpa @jrbl @nparlante 

"Proposal: We propose to build a utility which lists, for each problem in the course, its "settings", as well as some of the information it inherits from its Subsection, namely: Due Date, Release Date, Grading Type.  Each problem's title can be a link to the Studio page for the unit that the component is a part of, so that if a user spots something on the page that needs editing, they can quickly navigate to the where they can edit it.  Later on, we may make settings editable in-place on this page, perhaps even in bulk, but that won't be part of this release.  "

![screen shot 2014-07-11 at 12 04 27 pm](https://cloud.githubusercontent.com/assets/3598201/3557314/43dd1282-092e-11e4-8e9c-8fc4f6f95155.png)
![screen shot 2014-07-11 at 12 04 14 pm](https://cloud.githubusercontent.com/assets/3598201/3557313/43d0a4ca-092e-11e4-9af0-e4bf7be9c235.png)

So I have mixed feelings about this approach to testing.

First, I like what you're doing, creating random course content and then testing for it; I think this kind of input chaffing is valuable for flushing out input-based problems with the data pipeline, and I wish we did more of it. If you're going to do this, though, there are a few principals that you should follow, that I'm not sure I see here:
    * The thing that reads things and the thing that writes things shouldn't share data structures, because if they do you can't be certain that the reading thing is reading the correct stuff. For example, you should query a unit for the number of sections, rather than relying on numSections below.
    * On failures or errors, you want to always output the set of inputs used to generate the error or failure, so that future debuggers can characterize the problem. The simplest way to do this is to produce output prior to each of your asserts, but I think if you check the pyUnit docs, there's syntax for outputting a formatted message when a test fails, and using that might be nicer.
    * Tests should run in a predictable amount of time. If a test run takes 15 minutes, it should always take 15 minutes, at least until the test suite changes. Be sure that different random inputs don't cause unfortunate runtime variance.

Beyond those general points, though, I have another concern that you're not doing more focused testing. They say sometimes that in computer science there are only three numbers: 0, 1, and many. It would be good to be clear what your base cases are (an empty course, a course with one unit, a course with several units, etc.) and explicitly test that those things work the way you expect. This may require separate test classes with their own setUp functions, but they'll be small classes, and it's worth it to build the confidence; I suspect 80% or more of the problems that can arise will be caught by a small set of carefully selected base cases.  In most projects most of the time, this is actually considered sufficient, and then the kind of chaffing you're doing here is considered bonus material for belt-and-suspenders safety.

Also a few carefully defined base cases may let you build less elaborate random test courses.