VFP and VDP configurations

[Nils Goroll]

Hi,

at first, I found Rezas concept appealing and there are some aspects which I
think we should take from it:

- take the protocol-vpfs v1f_* h2_body out of the game for vcl

- format specifiers:

	- have:

	  (gzip), (plain) *1), (esi)

	- ideas:

	  (br), (buffertext) *2)

	esi being a format which can contain gzip segments, but that's would
	be opaque to other vfps

- the notion of format conversion(s) that a vfp can handle, e.g.

	- have:

	  esi: (plain)->(esi), (gzip)->(esi)

	  gzip: (plain)->(gzip)
	  ungzip: (gzip)->(plain)

	- ideas:

	  br: (plain)->(br)
	  unbr: (br)->(plain)

	  re: (plain)->(plain)

	
But reflecting on it, I am not so sure about runtime resolution and these
aspects in particular:

- "algorithm (...) can reorder the candidates if that allows a match."

- "(A VFP) can (...) add new VFPs to the candidate list, remove itself, remove
   other VFPs, or delete itself or other VFPs

I wonder how we would even guarantee that this algorithm ever terminates.

So I think we really need to have VCL compile time checking of all possible
outcomes:

- Either by keeping track of all possible filter chain states at each point
  during VCL compilation

- or by restricting ourselves to setting all of the filter chain at once.

The latter will probably lead to largish decision trees in VCL for advanced
cases, but I think we should start with this simple and safe solution with the
format/conversion check.

Nils

*1) "(text)" in reza's concept

*2) not sure if this is a good idea, maybe multi segment regexen are the better
    idea