Yield to newly bred threads

When we breed threads without a delay, we should make an effort to let
them run as soon as possible and not have the cpu occupied with the
herder code.

This will increase the overhead due to additional context switching for
the benefit of reducing latencies until new threads get to run.

Effect seen with this vtc by @Dridi:

    varnishtest "over-breeding"

    varnish v1 -arg "-p thread_pools=1 -p thread_pool_min=10"
    varnish v1 -vcl {
            backend be none;
    } -start

    varnish v1 -expect MAIN.threads == 10

Tested with the following script:

    ./varnishtest -i -k -j40 -n1000 tests/as_above.vtc |
    awk '/^#/ { print $5; }'|
    sort |
    uniq -c

Multiple runs show a consistent drop of failed tests:

    before | after
    -------+------
        76 |    18
        67 |    24
        66 |    18

bin/varnishd/cache/cache_wrk.c

@@ -53,6 +53,7 @@
 #include "config.h"
 
 #include <stdlib.h>
+#include <sched.h>
 
 #include "cache_varnishd.h"
 #include "cache_pool.h"
@@ -478,7 +479,10 @@ pool_breed(struct pool *qp)
 		VSC_C_main->threads++;
 		VSC_C_main->threads_created++;
 		Lck_Unlock(&pool_mtx);
-		VTIM_sleep(cache_param->wthread_add_delay);
+		if (cache_param->wthread_add_delay > 0.0)
+			VTIM_sleep(cache_param->wthread_add_delay);
+		else
+			sched_yield();
 	}
 
 	AZ(pthread_attr_destroy(&tp_attr));