Correct VipsArea ref count in PNG buffer output

Prevents a leak that includes a dangling/indirect reference to the buffer containing the compressed PNG data.
```
==10876== 179,884 (1,568 direct, 178,316 indirect) bytes in 28 blocks are definitely lost in loss record 4,832 of 4,859
==10876==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10876==    by 0x82A0610: g_malloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==10876==    by 0x7B92D83: vips_area_new (type.c:233)
==10876==    by 0x7B92E88: vips_area_new_blob (type.c:295)
==10876==    by 0x7B6F4DC: vips_foreign_save_png_buffer_build (pngsave.c:210)
==10876==    by 0x7B96258: vips_object_build (object.c:338)
==10876==    by 0x7BA0C63: vips_cache_operation_buildp (cache.c:765)
==10876==    by 0x7BA5698: vips_call_required_optional (operation.c:762)
==10876==    by 0x7BA6455: vips_call_by_name (operation.c:802)
==10876==    by 0x7BA689B: vips_call_split (operation.c:906)
==10876==    by 0x7B6CF16: vips_pngsave_buffer (foreign.c:2568)
```
This should be the last of the leak-related fixes discovered as a result of the scenarios I've been soak testing.