Overhaul of prodUpdate compression and archiving:
New task replaces three existing CompressProdUpdate tasks
New ID columns all over the place
With schema updates, prodUpdateArchive can be deprecated. After
database updates, running the new task manually* may be a good
idea. It needs to rebuild prodPriceHistory and prodDepartmentHistory
from scratch to assign foreign keys correctly.

* command: php FannieTask.php ProdUpdateMaintenanceTask
BUGFIX: wrong variable in new produpdate task
Corresponding houseCoupons.description update, fannie-side
Updated DB structure for product changelog tables
Deprecating table vendorLoadScripts
Cleaning up database cruft. Got rid of:
* fannie.op.AdDates
* fannie.op.batchMergeLC
* fannie.op.batchMergeProd
* fannie.op.CashPerformDay_cache
References to these tables are mostly gone from the code base.
Cashier performance data will be cached in either
CashPerformDay or CashPerformDay_cache depending which is actually
a table. Ditto for the report that uses that data.

SQLManager has a new isView() method and I tweaked the adodb library
to correctly detect mysql views.
Deprecating batch priority views. The idea of sales batch priority
may still be useful in a multi-store environment, but enforcing
the priority rules via five cascading views is not the right
approach. These were not actually being used AFAIK. The references
in the nightly.batch.php job were on the MSSQL side.
Deprecating batchowner. Updated model adds an 'owner' column directly
to the batches table. The separate table isn't necessary with
the better update mechanism. Data is migrated automatically.
Batch tools work with either schema.
Departments table expanded to include margin and salesCode columns
instead of using deptMargin and deptSalesCodes table. Editors maintain
both tables. Dependency removal in other reports and tools not
done yet.
BUGFIXES: cache task/job had an incorrect DB variable,
ditto for prodUpdate, batch report had a stray reference to
batchowner
Finished removing references to deptSalesCode and deprecated it.
I actually remembered to update the sample data this time.
FanniePage::readinessCheck as a method to see if any prerequisite requirements
for a page are not met. There are some cases where verifying data
has been entered is helpful. It could also be a place to do things like:
* Table X does not exist. Click here to go create it.
* Table Y needs to be updated. Click here to do so.
Deprecating fannie likeCodeView. The way it was being used
upcLike is a drop-in replacement.
Expanded memtype table deprecated memdefaults. memdefaults has not
been removed from default install yet but tools prefer memtype
if available and maintain values in both.
Deprecated fannie table unfiCategories. vendorDepartments is the
vendor-generic replacement
Deprecating unfi_order, unfi_diff, and unfi_all in Fannie. They
were only used by legacy tools and the more generic vendor structures
are an acceptable replacement. The "unfi" table can probably go
to but I have to review the codebase more carefully than just
grepping for the table name since it's a common string.
Helper methods in FanniePage for common readinessCheck scenarios.
Proof-of-concept in department settings report.
ProdUpdateModel should not complain about prodUpdateArchive missing
WFC internal reporting adjustment
Deprecating newBalanceToday_cust for ar_live_balance. This was 99%
done already. I just cleaned up code comments to refer to the
correct table.