Fixes #4705.

Note that libjpeg will print a warning to stderr if there are many
extraneous bytes, but can be silent if the extraneous bytes can fit
into its int32 bit-buffer for Huffman decoding. I'm guessing that
this is why whatever encoder that produced the image filed for issue
4705 did not realize that they are, strictly speaking, generating an
invalid JPEG. That issue's attached image has two extraneous bytes.

For example, piping the program below into libjpeg's djpeg program
will print an "18 extraneous bytes" warning, even though N == 20.

$ cat main.go
package main

import (
        "bytes"
        "image"
        "image/color"
        "image/jpeg"
        "os"
)

const N = 20

func main() {
        // Encode a 1x1 red image.
        m := image.NewRGBA(image.Rect(0, 0, 1, 1))
        m.Set(0, 0, color.RGBA{255, 0, 0, 255})
        buf := new(bytes.Buffer)
        jpeg.Encode(buf, m, nil)
        b := buf.Bytes()
        // Strip the final "\xff\xd9" EOI marker.
        b = b[:len(b)-2]
        // Append N dummy 0x80 bytes to the SOS data.
        for i := 0; i < N; i++ {
                b = append(b, 0x80)
        }
        // Put back the "\xff\xd9" EOI marker.
        b = append(b, 0xff, 0xd9)
        os.Stdout.Write(b)
}
$ go run main.go | djpeg /dev/stdin > /tmp/foo.pnm
Corrupt JPEG data: 18 extraneous bytes before marker 0xd9

The resultant /tmp/foo.pnm is a perfectly good 1x1 red image.

R=r
CC=golang-dev
https://golang.org/cl/7750043