Add DeidentificationMethod and DeidentificationMethodCodeSequence to json

[CGSchwarzMayo]

This parallels my PR to bids-specification:
bids-standard/bids-specification#1772
bids-standard/bids-specification#1709

The goal is to add DeidentificationMethod and DeidentificationMethodCodeSequence to json, so that users downstream have a chance to be informed of whether some tags were scrubbed and/or if any de-facing or other image scrubbing was applied.

From our email discussion, I understand that you will probably not merge this until bids-specification merges theirs. I thought we could iterate on this, if needed, in the meantime.

Thanks for your consideration,
Chris Schwarz
Mayo Clinic

[neurolabusc]

@CGSchwarzMayo thanks for your work on this. I do like the basic idea, but it is worth noting that a lot of the speed of dcm2niix derives from a one-pass conversion where we need to be mindful of the memory demands. Already, we compile dcm2niix with extra stack size for the Windows operating system. It looks to me that we need to pre-allocate 10 fields (MAX_DEID_CS) each with three kDICOMStr (66 bytes) and one kDICOMStrLarge (256 bytes), so the footprint is an additional 4560 bytes for each and every DICOM file. The concern here is if a user wants to process a top level folder that contains tens of thousands of individual DICOM files. If we really need this level of verbosity, I think we will have to read this once per output NIfTI image (e.g. once for an entire 4D fMRI dataset), not once per DICOM file (e.g. once per 2D slice for non-enhanced DICOM).

Let me see if I work with your PR and the validation dataset you provided to retain the functionality you propose without the overhead.

[CGSchwarzMayo]

Thank you for your help and consideration! I agree that it would be reasonable to assume that this tag is consistent across an image series.