Fixing issue in AssembleMatType procedure

[timryanb]

• Our nightly benchmark tests caught a change in the modal analysis results of one of our pytacs examples (benchmarks can also be run locally using $testflo -b .)
• I narrowed the problem down to this line of code in the assembleMatType procedure which was causing TACSFrequencyAnalysis to behave differently
• The problem is that getMatType isn't an additive procedure (like addJacobian) so everytime the auxiliary element contribution is computed, it overwrites the element contribution
• The fix to this was to always split out the auxelem matrix contribution and then scale (rather than conditionally doing so)
• I also added a new modalProblem integration test case to catch this in the future

[A-CGray]

What's the reason for this addition?

[timryanb]

Other TACS problems (StaticProblem/TranientProblem) may have set an AuxElem loads in a previous call. This line makes sure that AuxElems is empty at the begining of each ModalProblem analysis, since we have no use for them here. Setting this to None in Python is equivalent to setting it to NULL in c++