MINOR: balance uri: added 'whole' parameter to include query string in hash calculation

This patch brings a new "whole" parameter to "balance uri" which makes
the hash work over the whole uri, not just the part before the query
string. Len and depth parameter are still honnored.

The reason for this new feature is explained below.

I have 3 backend servers, each accepting different form of HTTP queries:

http://backend1.server.tld/service1.php?q=...
http://backend1.server.tld/service2.php?q=...

http://backend2.server.tld/index.php?query=...&subquery=...

http://backend3.server.tld/image/49b8c0d9ff

Each backend server returns a different response based on either:
- the URI path (the left part of the URI before the question mark)
- the query string (the right part of the URI after the question mark)
- or the combination of both

I wanted to set up a common caching cluster (using 6 Squid servers, each
configured as reverse proxy for those 3 backends) and have HAProxy balance
the queries among the Squid servers based on URL. I also wanted to achieve
hight cache hit ration on each Squid server and send the same queries to
the same Squid servers. Initially I was considering using the 'balance uri'
algorithm, but that would not work as in case of backend2 all queries would
go to only one Squid server. The 'balance url_param' would not work either
as it would send the backend3 queries to only one Squid server.

So I thought the simplest solution would be to use 'balance uri', but to
calculate the hash based on the whole URI (URI path + query string),
instead of just the URI path.
diff --git a/doc/configuration.txt b/doc/configuration.txt
index 3fc77a0..1253357 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -1311,18 +1311,20 @@
                   weight on the fly will have no effect, but this can be
                   changed using "hash-type".
 
-      uri         The left part of the URI (before the question mark) is hashed
-                  and divided by the total weight of the running servers. The
-                  result designates which server will receive the request. This
-                  ensures that a same URI will always be directed to the same
-                  server as long as no server goes up or down. This is used
-                  with proxy caches and anti-virus proxies in order to maximize
-                  the cache hit rate. Note that this algorithm may only be used
-                  in an HTTP backend. This algorithm is static by default,
-                  which means that changing a server's weight on the fly will
-                  have no effect, but this can be changed using "hash-type".
+      uri         This algorithm hashes either the left part of the URI (before
+                  the question mark) or the whole URI (if the "whole" parameter
+                  is present) and divides the hash value by the total weight of
+                  the running servers. The result designates which server will
+                  receive the request. This ensures that the same URI will
+                  always be directed to the same server as long as no server
+                  goes up or down. This is used with proxy caches and
+                  anti-virus proxies in order to maximize the cache hit rate.
+                  Note that this algorithm may only be used in an HTTP backend.
+                  This algorithm is static by default, which means that
+                  changing a server's weight on the fly will have no effect,
+                  but this can be changed using "hash-type".
 
-                  This algorithm support two optional parameters "len" and
+                  This algorithm supports two optional parameters "len" and
                   "depth", both followed by a positive integer number. These
                   options may be helpful when it is needed to balance servers
                   based on the beginning of the URI only. The "len" parameter