Add config validator rule

[jkuszmaul]

And a rule that creates a test to confirm that, for a given config:

• Remote timestamp channels are all specified and specified correctly.
• Logs for any given node are fully self-consistent (i.e., won't require --skip_missing_forwarding_entries)--note that this should be configurable, because you may only care about this for a few nodes.

[AustinSchuh]

Turns out our SF logs have some big problems because they didn't log all the data everywhere.

[AustinSchuh]

There is an initial validator that exists. Looks like it doesn't validate:

    {   
      "name": "/node1",
      "type": "Test",
      "source_node": "{{ NODE1 }}",
      "logger": "NOT_LOGGED",
      "destination_nodes": [
        {
          "name": "{{ NODE2 }}",
          "priority": 2,
          "time_to_live": 500000000,
          "timestamp_logger": "LOCAL_AND_REMOTE_LOGGER",
          "timestamp_logger_nodes": ["{{ NODE2 }}"]
        }
      ]   
    },  

is useless (We don't support anything other than NODE1 in the timestamp_logger_nodes list).

[AustinSchuh]

Same goes for:

    {   
      "name": "/node1/aos/remote_timestamps/node2/miss-spelling",
      "type": "aos.message_bridge.RemoteMessage",
      "source_node": "{{ NODE1 }}",
      "logger": "NOT_LOGGED",
      "destination_nodes": [
        {
          "name": "{{ NODE2 }}",
          "priority": 2,
          "time_to_live": 500000000,
          "timestamp_logger": "LOCAL_AND_REMOTE_LOGGER",
          "timestamp_logger_nodes": ["{{ NODE2 }}"]
        }
      ]   
    },  

where someone typos the RemoteMessage channel. We should confirm all RemoteMessage channels are in use.

[jkuszmaul]

With 827bd21, I think we are catching the primary categories of issue that we wanted to catch with this. Additional things can be added as needed.