Preserved Memoize decorator calls in score manager.

This is a null commit. (Meaning that a single line was changed trivially only
to allow this commit message to enter the log.)

Score manager py.test performance (492 tests):

    * without memoization: ~75 seconds
    * with memoization: ~68.5 seconds

CONCLUSION: there's a bit of voodoo involved in the way all of the different
memoization patterns interact with Sphinx. (The instigating factor kicking off
this particular integration effort being the apparent bug that Sphinx 1.2 can't
handle classes that redefine __get__.) But even given the voodoo the various
memoization patterns work great in the Score Manager. Why? Because the Score
Manager memoizes only single objects that are implemented as private
properties ...

    @property
    @systemtools.Memoize
    def _build_file_wrangler(self):

    @property
    @systemtools.Memoize
    def _distribution_file_wrangler(self):

    @property
    @systemtools.Memoize
    def _maker_module_wrangler(self):

... etc. And the performance improvements in py.test runtime are substantial:
69 seconds runtime is better than 75 seconds runtime when the batter is run a
couple of dozens times a day during development.

GOING FORWARD: the memoize decorator currently implemented in
systemtools/Memoize.py can be considered safe. But the trick is to use the
decorator only according to the one pattern shown and tested in the Score
Manager: apply the decorator against a no-argument property and all will be
well. (This could be applied to the parser, for example, if that were desired.)

GOING FORWARD: it's possible that the Memoize decorator could be removed from
the Score Manager after Score Manager development completes. But there's really
no reason to remove the decorator after Score Manager development completes. So
the decorator will remain in public releases unless some other factor arises
in the final phases of development.