SSP-1828 Default to Template objectStatus value in save dialog

In edit mode we want the "Active Template" checkbox to be checked or
not depending on current Template objectStatus. In create mode we
want the checkbox to not be checked, i.e. create an inactive Template,
e.g. to support a quasi-"draft" mode.

The create mode behavior just happened to work previously, but the edit
mode behavior did not. This was because the form was being reset
on "show", so it was mostly by accident that either case worked.

But when I moved the line that initializes the activeness checkbox
into the show event handler, I noticed that edit mode exhibited the
opposite behavior, i.e. always checked rather than always unchecked.

This was because the JSON deserialization was running against a
singleton Plan model. The latter extends from AbstractBase, and uses
populateFromGenericObject() on it to consume the JSON. Because the
target object had already been initialized once, though, the flags it
used to coordinate between 'active' and 'objectStatus' fields had
been set in such a way (statusFieldsInitialized=true) that when
'active' was then set again, and with a null or undefined value (which
will always be the case when reading an object back from the server),
it thought the change was coming from the UI, not the server, and would
overwrite the value of 'objectStaus' back to the default ('ACTIVE').
SSP-1828 Default new Plans to active

When in edit mode, the proposed active state will be the Plan's current
status. This worked in rel-2-0-patches for 2.0.1 as of
dac9036fbd2f43eb93bfb83c400db0af111a0c9d and appears to match the
current behavior in 2.1.0 at the same time.

That *new* Plans were defaulting to inactive, though, appears to
have been a regression from dac9036fbd2f43eb93bfb83c400db0af111a0c9d.
SSP-1828 Force Template to inactive in all save-as scenarios

So now the Template save dialog will propose an inactive status in
two situations where it didn't previously:

  1) Saving a copy of a previously saved, active Template, and
  2) Saving a Template-ized copy of a previously saved, active Plan
Revert "SSP-1794"

This reverts commit a95aa782a06d616711fa0230fbec49661c46451d.

The changes here were fine, but I think were obviated by work on
SSP-1828 which solves some of the same 'objectStatus'-'active'
client-side model field synchronization problems, but a little bit
more simply. So as part of that ticket I'm rolling back everything
for SSP-1794 and SSP-1760.
Revert "SSP-1760"

This reverts commit a2c7682415b7d587161ae8706b854454b7a4bc52.

The changes here were fine, but I think were obviated by work on
SSP-1828 which solves some of the same 'objectStatus'-'active'
client-side model field synchronization problems, but a little bit
more simply. So as part of that ticket I'm rolling back everything
for SSP-1794 and SSP-1760.
Revert "SSP-1760"

This reverts commit c6328eec7c219e421125ab6de847708dfe3a68dd.

The changes here were fine, but I think were obviated by work on
SSP-1828 which solves some of the same 'objectStatus'-'active'
client-side model field synchronization problems, but a little bit
more simply. So as part of that ticket I'm rolling back everything
for SSP-1794 and SSP-1760.
SSP-1828, SSP-1760 Restore useful line from a2c7682

I reverted a2c7682 because I felt later work on SSP-1828 resulted in
simpler changes that accomplished the same thing w/r/t synchronization
of objectStatus and active fields in the client-side model. But this
line, which makes sure the defaulting of objectStatus is reflected
in the value of the active field, was a helpful change that SSP-1828
did not address. So this commit restores it.
SSP-1828 Default several reference types to active in admin UI

Sets EnrollmentStatus, Color, and Tag records to active by default
when being created by the admin UI. Closely related to work
originally done in SSP-1794 and SSP-1760, but officially filed with
SSP-1828 because that ticket changed the approach a bit for managing
the 'active' and 'objectStatus' field synchronization, which I think
then created a regression that those other tickets had worked around.