Some other minor cleanup while I'm here.

string spec we pass to the VCC, to make future VCL/VMOD/VCC work easier.

Instead I ended up rewriting the entire .VCC file compiler, which was
so much easier than the first time, because now I know what it should do.

There should be no incompatibilities, but as always: Please test and report.

Before this change:

hostname:/proc/24139$ cat task/*/comm | sort | uniq
Backend poller
ban-lurker
cache-acceptor
cache-epoll
cache-main
cache-timeout
cache-worker
hcb-cleaner
MPL_busyobj
MPL_req0
MPL_req1
MPL_sess0
MPL_sess1
pool_herder
vsm_cleaner

fixes #1971

... in order to actually use it by default

When allocating ESI memory through objallocwithnuke, tell the sevedore
in storage_simple.c that getting less than requested, is not
interesting. At the same time, eliminate the possibility of getting
less memory than requested in sml_trimstore.

Fixes #1941

it is more consistent to hit vcl_miss{} every time for these objects,
as opposed to vcl_pass{} most of the time but occationally vcl_miss{}.

This also almost entirely takes the TTL of HFP objects out of the
picture, in the sense that any cacheable object fetched as a result
of HFP will be put into the cache and be usable, rather than the
HFP preventing cacheable objects for whatever TTL the HFP might
have.

See c00076 for an example of this.

Idea from Devon H. O'Dell (dho at fastly dot com).

This might happen during pass'd requests or in a multi-tier setup.
Fixes #1955.

Fixes: #1967

If an object marked OF_IMSCAND is used as the template during backend
IMS revalidation, and the new object also is marked OC_F_PASS
(hit-for-pass) in vcl_backend_response, the resulting object would
(though ObjCopyAttr) have both OF_IMSCAND and OC_F_PASS. The object
could then be used again for backend IMS revalidation (since it has
the OF_IMSCAND flag), which would cause troubles as the body would by
this time be deleted.

Fix by not considering objects marked OC_F_PASS as a stale object
candidate during lookup.

Fixes: #1956