2014.12.18 MSS Code Factory 2.0.12708 Updated CFSecurity 2.1 model, run garbage collector every 100 files

I've tweaked the MSSBamCFGenFileObj to overload expandBody(), invoking the superclass implementation and
then running System.gc() every 100 files produced.  With any luck, I'll see some performance improvements,
especially on large projects.

The CFSecurity 2.1 model has been updated to add a Description to Cluster, password reset attributes
for the SecUser object, and the addition of a DevName attribute to a SecSession.  Last but not least, a ProxyUser
parent has been added to SecSession, so that when artificial jumps into a system.system.system session
occur, there is tracking as to *who* is responsible for that leap into the system data space.

The device name of a SecSession is *not* a lookup key, because it will be set to "web" for security
manager interface logins, and it will not be legal to specify "web" as a device name in the Add Device
form in the future.  (There are a lot of rules and checking I need to go back and implement once I'm
done fleshing out the skeleton of the interface.  If you allow garbage in, you get garbage out.)

I'll also be modifying the interpretation of the $SchemaName$Cluster environment variable used to
deploy the WARs to specify the cluster name, followed by a single space, followed by the description
string for the cluster.  I'd rather get that description from the environment rather than having to
add a form and a step to the server initialization/registration process.

I've implemented the SHA-512 password hashing for the security manager HTML password.  As long as you
deploy the WAR over HTTPS instead of HTTP, you should find the security of the HTML interface quite
acceptable, rough though it is.  There is a lot left to code -- the skeleton for HTML and application
password resets, initializing the application password to the HTML password for one-time use in changing
the application password, cancelling password resets by entering the existing password, and password
change forms.  I'm going to hide the application password values behind a double-blind of taking
an SHA-512 hash at the client and applying another SHA-512 hash to that at the server as the password
for an application user.  So you won't be able to *set* the application password through the security
manager web interface, only reset it to whatever your HTML password is.  We don't know what it is, we don't
want to know what it is.  La la la la la.