Also change the DRIVER_MODIFICATION number even though I'm not sure if
this should be done since this shouldn't change anything in the driver
per se.

Add WITH_CURL compilation option.

If compiled with WITH_CURL = YES, CurlUsage.template file will be added
and it's records will be created. curl.h will be included.
First record - UseCurl - should futurely toggle curl usage in the
Driver.

No need to use getIntegerParam in this context if we already have the
value argument.

Using this along with to-be-added CURLOPT_PASSWORD would expose
credentials in the network.

I leave it in the driver as a means to completely express the API
functionalities, but there should be better ways of setting your
credentials if you mean to.

Probably will add a configuration file for that in the future.

Same warning about last commit: this shouldn't be used but it's left
here as an option for quick testing and better expressing the API
functionalities.

For actual credentials usage future records should add a path for a
configuration file containing the credentials.

Should be used to load the file contents and put them
into the correct parameters. Uses a very similar mechanism from
NDFile.template and functions from asynNDArrayDriver.

For now it just checks if the file exists and is accessible, but not
it's contents.

Add CurlLoadConfig record and loadConfigFile function.

loadConfigFile() calls writeInt32 and writeOctet for all parameters
it can recognize, except username and password. For those,
loadConfigFile() calls curl_easy_setopt without ever setting the
parameter value.

This means setpoint and RBV values for all parameters can be different,
so I add readback values for all records.

writeInt32 and writeOctet are called inside loadConfigFile(), which is
called inside writeInt32. In my understanding this cannot lead to any
infinite loop since CurlLoadConfig record has no "ASYN_" prepending it's
name, so it's impossible for it to call writeInt32 on itself.

Also, I think this is thread safe because the function is only supposed
to be called inside writeInt32, which is supposed to be already locked.

Readbuffer is a char vector just so we can copy all needed bytes to it.
writeCallback should simply add stuff to the buffer.

readImage clears buffer before adding to it. Unfortunately I think clear
cant be called inside writeCallback because it's called more than one
time per read.

This is obviously needed and acquisition will fail without this.

WITH_CURL = YES/NO is used to tell the compiler to use or not use curl.
I add an example in configure/CONFIG_SITE to make it easy for people to
enable/disable this in future.

Curl is added as an option both at compile and at runtime.

If compiled with WITH_CURL = YES at configure/CONFIG_SITE.local,
curl option will be enabled at runtime but default will still be UseCurl
= NO.

If record $(P)$(R)UseCurl = YES, then code will get image from URL using
libCurl instead of graphicsMagick. Some curlOptions are configurable as
records. More can be easily added.

The CurlConfigFile.template is based on NDFile.template, but a bit
different, so I preferred to create a new one instead of including the
one that already exists. Maybe this can be modified in future.

Describe all new records along with brief driver description.

Comments to make it easier to load Curl template file if compiled with
WITH_CURL=YES

Add records and driver description into ADURL.rst and code comments in
each function.

Since this PR is supposed to add new functionality, I reset patch number
and add to revision number.

Update with info about header file change and curl functionality added.

Post merge of doc branch into add-curl-option.