Proposed usage for logging macro wrappers provided by rclcpp (not considering logger objects at the moment)

The purpose for wrapping the rcutils macros in the first place is to inject default names and/or name suffixes to log calls.

For comparison, ROS 1's rosconsole does the following:

1. uses "ros.<package_name>" as the name for unnamed log calls (a default name of sorts, to allow for some automatic grouping of logging messages even if users just call ROS_INFO)
2. prepends "ros.<package_name>" to all named log calls e.g. ROS_INFO_NAMED, presumably to distinguish them from other non-ros loggers, e.g. rqt_gui_py_node exposes loggers like PyQt5.uic.properties
3. doesn't provide a way to avoid the suffix when using the macros from what I can tell (you don't have to use the macros though)

The proposal for ROS 2 is to do something similar by setting a default name/prefix, but also provide ROS_INFO_FULLNAMED that allows users to provide the full logger name if they want to.

Concrete proposals:

1. Default name of just "<package_name>" for nameless log calls (when using ROS_INFO)
2. Default name is prepended as a prefix for named calls (when using ROS_INFO_NAMED)
3. No prefix added for fully-named calls (when using ROS_INFO_FULLNAMED)

Reasoning:
Speaking with a couple of people it seems that we don't feel that having the "ros" prefix for the default name/prefix is that necessary, but that a default of some sort is still needed, so we can just go with "<package_name>". IMO if a user calls ROS_INFO_NAMED in the same file as ROS_INFO they should go to the same parent logger (different child for the named one), suggesting that whatever the default name is it should continue to be prepended even in the case of ROS_INFO_NAMED.

However, most people I spoke to were surprised that the package name was always being prepended without a way to override it, so we can also add ROS_INFO_FULLNAMED, which doesn't do any name modification, it just passes it through to rcutils.
Examples when you might want to use ROS_INFO_FULLNAMED:

1. someone wants to group all of their packages relating to robotX under a common root logger
2. someone has 2 instances of robotX and wants them to publish under separate root loggers based on their robot name.

This PR has some usage examples.