RuleBasedEditor suggested improvements

[jouvin]

During #151 review of the initial RuleBasedEditor code, some areas for future improvements have been identified:

• Use a dispatch table to replace the if...elsif.. blocks related to line formats and value formats in several methods to make the maintenance easier and the code easier to extend. This could possibly allow to support formats not defined in the base RuleBasedEditor.
• _parse_rules() contains two if ( $negate ) ... blocks that implement an XOR. Would be better replaced by PErl xor but attempt to do it during Rule based editor #151 failed...
• In _apply_rules: decide if a failed rule should be signaled with an error or warning. Note that this happens mainly because of internal errors (RuleBasedEditor bugs or incorrect rules, e.g. incorrect format paramaters). And that if it should be a warning, this probably means that internal errors in other methods should also be warnings...
• Add a specific unit test for _parse_rules() method rather than rely on the _apply_rules() test (rbe_rule_parser.t).

[stdweird]

• consistent return values: undef on failure, SUCCESS on success (see eg _commentConfigLine) adn act upon them in _apply_rules

[stdweird]

• export the constants also as readonly, so the can used as variable in the string rather than concatting, eg.
  use "DiskFlags:dpns->DiskFlags:dav;$LINE_FORMAT_KW_VAL;$LINE_VALUE_ARRAY", rather than current "DiskFlags:dpns->DiskFlags:dav;".LINE_FORMAT_KW_VAL.";".LINE_VALUE_ARRAY,
• refactor the unittest code by introducing some function instead of copy/pasting the tests
• unittests should be more abstract and try to test all combinations

[stdweird]

@jouvin moving this milestone, afaik, you are on holiday for the remainder of 16.8