Extend core API to tag byte ranges -- first use case: Avoid the use of PacketTag in LTE PDCP and RLC, ByteTagging only their headers

We have an on-going discussion on the problems of Packet (and Byte) tags, and a possible solution, which consists in tagging only specific byte ranges (and not the entire packet). The discussion is here: https://mailman.isi.edu/pipermail/ns-developers/2019-February/014670.html.

This merge request uses a patch contributed by Tom to expose to the users the appropriate API to tag byte ranges; that API is then used to tag PDCP and RLC header in the LTE module.

The reason is that, as pointed out in merge request !8 (closed), the NR and mmWave module are performing some operations on the Packet that are invalidating the PacketTags added by these two layers. On the other hand, using ByteTags without this patch would add overhead to the entire simulation, and lead to fatal crashes when TCP does a lot of retransmissions and byte combination. So, the natural follow-up is to byte-tag only the headers, that are removed at the other side of the communication (hence without conditioning other layers).

Points which need inputs:

• Should the API be exposed directly to the user, or should we implement first a more restriction version (something such as Packet::AddHeaderWithTag(const Header &h, const Tag &tag)?
• In case we expose the low-level API directly, what meaning should the parameters have? For instance, to tag a 32-bytes long header, what is the best API?

AddByteTag (first, offset=0, offset=31)
AddByteTag (first, offset=0, length=32)
AddByteTag (first, position=1, position=32)

Last point: As RLC TM does not have headers, the delay report functionality has been disabled (reporting a static 0 as delay). Users that rely on this should use PDCP instead (which, in all cases, adds a header).