Add logger roscpp_internal.connections.

* Implemented rate-control-topic and rate-control-max-delay.

* Made rate control comparisons compare to time publisher rather than wall time.

* Added a check and a warning if the header is not the first in the message,

and removed an unnecessary import.

* Some quick formatting changes to simplify the final pull reuqest.

* Why is there little whitespace changes.

* Tabs to spaces, and other whitespace fixes.

* This is the last whitespace fix I swear.

* Removed unused function parameters.

* Fixed a bug preventing code from building after commit ecfb85f.

* Aligned print messages for rosbag PAUSED/DELAYED/RUNNING

* add test code for multibyte string

* merge Python 2 and 3 code paths

… confusing.

For example, [this warning msg](https://travis-ci.org/wg-perception/people/jobs/202019288#L3737) (in this [PR](wg-perception/people#49)):

 ```
 * WARN: unrecognized 'group' tag in <node> tag. Node xml is <test name="$(arg testnode_name)" pkg="rostest" test-name="hztest_test" type="hztest">
    <group unless="$(arg expected_success)">
      <node args="-r 0.5 $(find face_detector)/test/face_detector_noface_test_diamondback.bag" name="play" pkg="rosbag" type="play"/>
      <param name="hz" value="0.0"/>
    </group>
```

This is confusing because the tag in question is actually `<test>`, not `<node>`. Although the warning message refers to the exact <test> tag, I didn't try to read it because I was told the issue is with <node>, not <test>.

With this PR the message becomes a bit verbose but hope the readers get better idea.

fixes CORE-6641

Consider the following scenario for a message G with the following
versions:

G0 -- rule.bmr --> G1 -- auto-generated rule --> G3

where G3 is the CURRENT msg, and G2 is the BAG message that needs
migration.

We need to check for a migration rule like this first:

G2 --> G3

instead of the backwards ones that were generated before this bug fix:

G2 --> G1

Note that the 'lazy' check to valid the rules in the make_update_rule
method makes that rule pass initially, but later it fails because
there's no rule for the sub fields.

refs CORE-6641

Checking the sub rules are also valid we allow to check for different
positions in the chain for the BAG message we need to migrate, because
we don't really know where it should go, and the 'lazy' check for valid
in the make_update_rule method makes the suggested rules pass almost
always, so we can easily get a rule in the wrong place that later would
fail because there are no rules for the sub fields.