multiple RV component texture group records results in duplicate horizons/logic fail

[brownag]

Noticed today that I had inadvertently checked two texture groups as RV for one of my component horizons.

The component wouldn't load via fetchNASIS_component_data() due to failing test_hz_logic(). The reason why was not immediately obvious from my NASIS horizon table.

Multiple RVs results in the duplication/overlap AFTER loading from DB when compressing the chorizon texture group table down to the texture field within the component SPC.

Was handy that this happened, as otherwise it would have persisted in there until I ran the RV validation, but it might be helpful to catch "multiple RV" issues with a more informative error message.

Also, should there be safeguards to prevent duplication of a record because of a many-to-one compression gone bad? or one that is "intractable" without a human decision? I can't currently think of a case where duplicating would be desired behavior.

[brownag]

This issue also applies to multiple RV structure group. Not as much of an issue with default rmHzErrors=FALSE as the duplication does not lead to loss of data, just logic errors which the SPC is generally more robust to now.

I fixed an issue that prevented from displaying the QC note about horizon errors detected, so users should be alerted to some aspect of the data quality issue. This works to detect duplication regardless of the source of the problem.

In the future we can develop a method that can take a list of components with horizon problems and give a better explanation about what is different between otherwise duplicated layers (#89)