ip4defrag: reassembled IPv4's `Length` is 20 less than correct value (forgot to add the header length)

In [defrag.go#L313](https://github.com/google/gopacket/blob/master/ip4defrag/defrag.go#L313) , the reassembled new IPv4 object's `Length` field is assigned by value of `f.Highest`.

The `f.Highest` was calculated by adding each fragment's reassembled payload length in [line 256](https://github.com/google/gopacket/blob/master/ip4defrag/defrag.go#L256) therefore it represents reassembled IPv4's payload length.

However, in an IPv4 header, the `Length` field is defined as total length, including both header length (20 in usual) and payload length. E.g., when decoding the new IPv4 payload, in `ipv4.DecodeFromBytes()` [L228-L236](https://github.com/google/gopacket/blob/master/layers/ip4.go#L228), the `Length` is used as total length. With this bug, eventually the reassembled and then decoded `ip.Payload` will be 20 bytes less than expected.

Therefore, the L313 should assign `f.Highest + 20` to `Length` (if we ignore the potential IPv4 header options).