Revisit how we handle FFN values in translations

[mattjdnv]

Revisit how we handle Feature Function (FFN) values in translations. Re-check the mappings and add pre/post processing as required.

This is in relation to #4737 , #4633 etc

[tdvorakcaci]

In general, I lean towards the camp of leaving data as is, that are valid combinations per TRD rules, and not forcing translations that automatically change attribution. TRD guidance changes and old TRD version data does not always match updated guidance.

HWT=7 are not actual places of worship, and FFN=850 HWT=7 should be valid. The actual place of worship within a monastery or convent should have the correct HWT (not 7) and FFN=931. I would be comfortable with HWT=2, 3, 4, 5, 6, 9, 11, 14, 15, 16, 20, 21 getting FFN=931 as they are all an actual place of worship. However, HWT=7 should not be translated to FFN=931.

[MikeTho16]

Agree with @tdvorakcaci. The best/safest approach for our project would be to preserve the values exactly as entered/imported. Presumably the data producers know what they are doing. They also may be acting on project specific guidance from their customer. The second best approach for us would be to at least preserve the values exactly as entered if the specification indicates those values form a valid combination and allow other values to possibly be changed (would be nice to get some sort of error or warning if this was the case).