Automunge

- performed a micro-audit on a specific segment of the processing functions
- associated with populating column_dict data structures
- found a few opportunities for cleanups for purposes of clarity
- that were mostly relics from awkward code reuse issues
- so column_dict specifications are a little more uniform now

- consolidated mnm6 and mnmx transformation functions by use of mnmx for mnm6 with defaultparams as floor = True
- added parameter support for the other numeric normalizations to accept default adjacent cell infill comparable to those updates from 4.88
- ie added adjinfill parameter support to MADn, MAD3, mnm3, mean

- added transformation function parameter 'adjinfill' into a few normalizations nmbr, mnmx, retn, DPrt
- such as to allow changing default numeric infill from mean imputation to adjacent cell
- adjinfill parameter can be passed as True/False, defaults to False
- this parameter is redundant with what can be specified with assigninfill to return sets with adjacent infill
- but thought it might be beneficial to have option for customizing default infills applied prior to ML infill
- I have a hunch that adjacent infill may be better suited as a default imputation
- because of inherent stochasticity
- but don't have evidence so for now primary numeric normalization default remains mean imputation
- also added a few code comments for clarity for assignparam parameters in these normalization transforms

- slight tweak to the box-cox power law transform function 'bxcx'
- no change in output, just resolved an inconsequential edge case printout
- associated with scipy stats implementation
- to avoid confusion

- found and fixed a small bug in src4 (ordinal search function)
- where was incorrectly producing a printout

- fixed inverison transform for bnwo for cases where a downstream categoric transform is performed
- found and fixed small bug in DPnb postprocess function
- new validation function to confirm that root categories in transformdict have corresponding processdict entries
- corrected an error message that had eroneously noted a scenario where a transformdict entry does not require a coresponding processdict entry
- so to be clear, every transformation category requires a processdict entry
- only in cases where a transformdict entry is being passed to overwrite an existing category already defined internal to the library is a corresponding processdict entry not required.
- transformation categories that are to be used as family tree primitive entries with offspring require a root category entry in transformdict for family tree definition
- I recomend defaulting to defining a family tree for all transformation categories used in transformdict