Also update set.saved(), to enable checking if an integer was saved.

re2 no longer does that since commit
848dfb7e1d7ba641d598cb66f81590f3999a555a.

This should hopefully fix a panic which has to be caused by forgotten
WS_Release() calls and which occurred close to VCL code which handles
re2 sets.

Redacted panic:

Panic at: Fri, 05 Apr 2019 19:15:24 GMT
Assert error in WS_Reserve(), cache/cache_ws.c line 236:
  Condition(ws->r == NULL) not true.
version = varnish-trunk revision af2bad23deb2470533158f9d99ad3f4968b8d231, vrt api = 9.0
ident = Linux,3.13.0-137-generic,x86_64,-junix,-smalloc,-sdefault,-hcritbit,epoll
now = 3999664.335146 (mono), 1554491669.714933 (real)
Backtrace:
  0x43c1bb: /usr/sbin/varnishd() [0x43c1bb]
  0x49e182: /usr/sbin/varnishd(VAS_Fail+0x42) [0x49e182]
  0x45d1ac: /usr/sbin/varnishd() [0x45d1ac]
  0x44d792: /usr/sbin/varnishd(VRT_String+0x22) [0x44d792]
  0x44de66: /usr/sbin/varnishd(VRT_SetHdr+0xf6) [0x44de66]
  ...(redacted for customer proprietary information)

See also https://github.com/varnishcache/varnish-cache/issues/2967
for a general discussion regarding an inconsistency in the WS_Reserve()
interface

Ref d8ae26b5a0b4a1102360a61a145e4730e52d68bc

compile_fail.vtc evidently takes longer than 60s when run in a
docker container.

The reason is the same as for
https://github.com/varnishcache/varnish-cache/issues/2708 :

VRT_priv_task may now return NULL for out-of-workspace errors, see
https://github.com/varnishcache/varnish-cache/commit/de2b431086a13b243dc8b3e71cd8697db1df2c7f

If RE2 reports the "DFA out-of-memory" condition for a failed set
match, the VMOD reports the error as well.