Create new group configurations page.

**Ticket**: [BLD-1121](https://edx-wiki.atlassian.net/browse/BLD-1121)

**Acceptance criteria:**
* Button (or something) on the Group Configurations page to create a new configuration. 
* Editable fields appear for: 
  * Group Configuration Name (required, ok if non-unique)
  * Group Configuration ID (READ-ONLY, required, numeric, must be unique within a course - can just increment sequentially for courses with no existing but take into account courses with existing group configurations created in the user_partitions value on Advanced Settings page - we must not overwrite any values.)
  * Group Configuration Description (optional)
* DO NOT show any Groups information on the front end (will be a separate story) but DO create default groups (2 groups, named Group A & Group B, both at 50% allocation) on the backend. (This should already be handled by the split_test module, but we should test to make sure this reflects correctly in the Group Configurations page.)
* Create button should save the group configuration.
  * Error message should appear if required fields are omitted upon save. 
  * User should stay in the New/Edit Experiment modal to correct the error. 
* Cancel link should not save but should close the new group configuration modal. 

**sandbox:** http://studio.olmar.m.sandbox.edx.org/

@andy-armstrong , @cahrens , @frrrances please review.
One other point: I think that performance of the tests is not important as the JavaScript tests take hardly any time. I think the bigger concern is team productivity. If we are writing unnecessary tests then we are wasting time that we could use more productively. I know that @nasthagiri was of a similar opinion that we should write fewer Jasmine tests and spend more time on Bok Choy since it is testing (mostly) the same logic.

If we do decide to use Bok Choy *instead* of Jasmine then we would need to have Bok Choy tests to contribute to the coverage reports. It wouldn't make sense to be tracking Jasmine coverage independently if we choose explicitly to not be aiming for complete coverage.

@jzoldak I guess we should have a meeting to discuss this and determine what approach the teams should be taking.