Moving energy matrices from hit maker

These should be placed in the point maker code, or even Yiqun itself,
as they are specific to that. For now I am placing them in the point
maker, but we could move them to Yiqun at a later date if it becomes
clear that is preferrable.

We also need to change access to StFmsDbMaker in our code from using the
global gStFmsDbMaker pointer to using GetMaker() (this came up in a
recent FMS software review), which requires accessing the make via its
name. Therefore I made this change, and I changed the StFmsDbMaker name
in the test macro to "fmsDb" for consistency with the STAR BFC chain.
Use trigger data to fill energy matrices

In my original version I read hits from the MuDST, but this turns out
to be inconsistent with Yuxi's implementation in StFmsHitMaker, where
he uses trigger data. I don't understand the difference - I thought the
MuDST should give the same - but for consistency in this debugging
phase I will keep it the same as Yuxi's version. We should think about
using the MuDST as the input for this, and try to figure out the reason
for the difference. Really, we probably need to support different types
of input, like the hit maker does - MuEvent, MuDST, trigger data etc,
to account for the different times the makes may be run (production,
or just someone regenerating hits with a new calibration).
Remove point maker dependence on hit maker

StFmsPointMaker previously needed to be passed a pointer to the
StFmsHitMaker, in order to access the energy matrices stored there. As
StFmsPointMaker now generates the energy matrices itself from the MuDST
it no longer needs it. I changed the test macro to reflect this as well.
Remove energy matrix code from StFmsHitMaker

This functionality is now located in StFmsPointMaker, where it is used.
There are still some changes from the official STAR version, that Yuxi
added for debugging, so I haven't reverted to the offical release,
though we should do so before releasing this code.