app layer protocols from streams vs packets

Regarding the discussions on PRs for [diameter](https://github.com/google/gopacket/pull/733) and [SMTP](https://github.com/google/gopacket/pull/587), what should the design be to handle application layer protocols from streams?

As of now, users of gopacket will hack their own code for layer 7 assembly. I wonder if any layer 7 protocols should be a part of this project -- it could make things simpler for gopacket if it doesn't try to accommodate any protocol, as does for example the Wireshark project.

Given a PDU (from a UDP packet or something you put together from reassembly.Stream callbacks) in buf, currently you do this:
```
gopacket.NewPacket(buf, layers.LayerTypeFoo, opts)
```
If you are decoding http, smtp, sip ... potentially no limit to payload sizes ... NewPacket doesn't seem like the right type of call. It is stretching the meaning of the word "packet". Should there be instead, a package for application layer (7) and some API that takes either a buffer (fully allocated, contains a single PDU from whichever lower layer) or a stream (in the form of a reader or callbacks). The client can then be provided with whatever API makes the most sense for that protocol. E.g. for http or smtp you'd want an API that lets you pass in an io.Writer.

@tadamra @notti @gconnell thoughts? Personally I just want the diameter branch into gopacket. Please suggest a design or course of action.