SSP-2814 Stop explicitly destroying SemesterPanels' nested View

Unsure if this will fix the reported bug, where MAP blows up deep in
its component destruction callbacks when you navigate to a different
tool. Specifically, it's blowing up with a trace that ends with:

  Uncaught TypeError: Cannot read property 'el' of undefined ext-all.js:21
  Ext.define.delayScroll ext-all.js:21
  Ext.define.onHeaderResize ext-all.js:21
  Ext.define.onHeaderResize ext-all.js:21
  Ext.define.afterComponentLayout ext-all.js:21
  Ext.define.notifyOwner ext-all.js:21
  Ext.define.callLayout ext-all.js:21
  Ext.define.flushLayouts ext-all.js:21
  Ext.define.runComplete ext-all.js:21

That delayScroll() is a function on Ext.panel.Table, which looks like:

 delayScroll: function(){
     var target = this.getScrollTarget().el;
     if (target) {
         this.scrollTask.delay(10, null, null, [target.dom.scrollLeft]);
     }
 }

So we're pretty clearly blowing up b/c getScrollTarget() returns
undefined. The impl of that method is:

 getScrollTarget: function(){
     var owner = this.getScrollerOwner(),
     items = owner.query('tableview');

     return items[1] || items[0];
 }

I'm *guessing* the query('tableview') is intended to return the
Ext.panel.Table's nested Ext.view.Table b/c that component's
source
(http://docs.sencha.com/extjs/4.1.3/source/Table2.html#Ext-view-Table)
has this line:

  componentLayout: 'tableview'

But if that nested component has already been destroy()ed, I'm
guessing it removes itself from 'owner' such that
owner.query('tableview') might return undefined, which would
explain the trace we're seeing. And that's what we're doing
(destroying the nested view before the wrapping view)
in SemesterPanelContainerViewController.destroy():

 for (var key in this.semesterPanels) {
     this.semesterPanels[key].getView().destroy();
     this.semesterPanels[key].destroy();
 }

So this patch just removes the explicit nested view destroy.

But if this theory were true, you'd expect to get the stack trace
every time you destroyed MAP, which doesn't seem to be the
case. So I'm not yet entirely sure whether this explanation or
the fix will actually hold water. Also don't know whether the
fix will have unintended consequences... the line it removes
was part of a larger attempt at dealing with problematic
MAP de-initialization behaviors.