Reorganize validation message level determination as a precursor to single rule disjunction

[GiaJordan]

This PR will help enable single rule disjunction by reworking how validation message levels are determined and the IsNA rule modifier introduced in #1200. The error/warning/no-message determination logic of all validation rules has been reworked to be compatible with this new rule modifier and has been simplified to be easier to maintain.

Rule compatibility with the IsNA modifier will be finished in a subsequent PR.

[GiaJordan]

@mialy-defelice resolving the conflicts was trivial; this is ready to be reviewed

[mialy-defelice]

@GiaJordan I see how to the functions were refactored for simplicity, but I am having trouble following how this enables single rule disjunction? Can you explain this again?

[GiaJordan]

@mialy-defelice single rule disjunction will be enabled with #1369
I separated the refactor from the feature addition for better organization and ease of review

[mialy-defelice]

@GiaJordan I guess my question came from this part of the description:

 The error/warning/no-message determination logic of all validation rules has been reworked to be compatible with this new rule modifier

How do these changes allow compatibility?

[GiaJordan]

How do these changes allow compatibility?

@mialy-defelice When the IsNA rule was introduced, it was introduced only for the type checking rules because it was specific to @/andrewelamb's use case then.

The logic for IsNA now is in get_message_level() which is used by all of the rules when determining which level of message to raise.

[mialy-defelice]

Ah gotcha, I understand now, thanks!

[GiaJordan]

@mialy-defelice no problem!

[sonarqubecloud]

Quality Gate passed

Issues
14 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
12.0% Duplication on New Code

See analysis details on SonarCloud

[mialy-defelice]

Pushing up to dev, then will merge single rule disjunction directly to dev.