Use static buffer for fake JPEG EOI marker as src->buf might not be allocated

Whilst investigating https://github.com/lovell/sharp/issues/6 I discovered via _valgrind_ that `src->buf` in `fill_input_buffer` sometimes hadn't been allocated (or had already been freed) and was causing heap corruption.

```
==21873== Invalid write of size 1
==21873==    at 0x772627B: fill_input_buffer (jpeg2vips.c:1116)
==21873==    by 0x833ACA5: ??? (in /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2)
==21873==    by 0x833B4AC: ??? (in /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2)
==21873==    by 0x83399B9: ??? (in /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2)
==21873==    by 0x83342EC: jpeg_finish_decompress (in /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2)
==21873==    by 0x7726537: readjpeg_free (jpeg2vips.c:187)
==21873==    by 0x7BA9187: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21873==    by 0x7BBAB1C: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21873==    by 0x7BC2828: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21873==    by 0x7BC2AE1: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21873==    by 0x773E216: vips_object_dispose (object.c:159)
==21873==    by 0x7BADABB: g_object_unref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21873==  Address 0xe347900 is not stack'd, malloc'd or (recently) free'd
==21873==
==21873== Invalid write of size 1
==21873==    at 0x7726282: fill_input_buffer (jpeg2vips.c:1117)
==21873==    by 0x833ACA5: ??? (in /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2)
==21873==    by 0x833B4AC: ??? (in /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2)
==21873==    by 0x83399B9: ??? (in /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2)
==21873==    by 0x83342EC: jpeg_finish_decompress (in /usr/lib/x86_64-linux-gnu/libjpeg.so.8.0.2)
==21873==    by 0x7726537: readjpeg_free (jpeg2vips.c:187)
==21873==    by 0x7BA9187: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21873==    by 0x7BBAB1C: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21873==    by 0x7BC2828: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21873==    by 0x7BC2AE1: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21873==    by 0x773E216: vips_object_dispose (object.c:159)
==21873==    by 0x7BADABB: g_object_unref (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3800.1)
==21873==  Address 0xe347901 is not stack'd, malloc'd or (recently) free'd
```

This was only occurring when decompressing JPEG data from a memory buffer via `vips_jpegload_buffer`. The file-based `vips_jpegload` equivalent does not trigger this problem.

By switching to a static buffer for the fake end-of-image marker I'm no longer experiencing this heap corruption and _valgrind_ is happy.