Folks, it has happened; i'm using threads for asynchronous downloads instead of processes.
The word fork is not to be found in the edbrowse source!

There are two places this occurs.

1. Download files in background.
This is not the default.
Use the bg command to turn this on.
Usually when a file is large and you just want to let it run in the background.
Type bglist for a list of the background jobs.
Careful, it's not a separate process, so if you quit edbrowse before the download is complete, it just stops and doesn't finish.

2. Download all the javascript files in the background and in parallel.
These can be large files so I'm hoping this speeds things up.
This is on by default because you usually want it, besides,
I really need folks to test it under various conditions
and find any weird race conditions or thread unsafe code or seg falts etc.
It works with curl+gnutls, which the process implementation never did.

Both of these have lots of corner cases, especially #1.
Download ftp files, gopher files, https files, several at onces, some large,
does it all work? Do they interact with each other?
Does the bglist command work?
Does it show the sizes of the downloads in progress?
Does a foreground download still give you the dots?

Are javascript files pulled from cache or put into cache, even when they download in background?
(This is important.)

Then there is a whole host of followup work, like putting off the async scripts til the end,
and maybe starting the js fetches even earlier at parse time,
and maybe fetching css files in background (which isn't done yet),
and on and on.
But first let's make sure I didn't break all sorts of things with this commit.

Set db3 and you'll see all the fetches and http codes etc in a jumbled order as the files are loaded.
Type jsbg to go back to a sserial order.

I've never touched posix threads before so give me a pat on the back for diving into something new.

Karl Dahlke