Merge pull request #75 from Qingtao-Cao/devel

One step back on whether to impose stringent control on requested URIs
Move obix_get_timestamp from client library to common library

Rename obix_get_timestamp() to get_utc_timestamp() since it invokes
gmtime_r() to convert calendar time into UTC based struct tm, and
move it from the obix-client library to obix-common library so as
to be used by test tools without having to link up with obix-client
library which requires libcurl as well.

Signed-off-by: Qingtao Cao <qingtao.cao.au@gmail.com>
Move the inclusion of XML headers from obix_utils.h to xml_utils.h

This frees obix_utils.h from XML headers so that test tools can
manipulate libobix-common without having to link up with libxml2.

Signed-off-by: Qingtao Cao <qingtao.cao.au@gmail.com>
Support ISO-8601 timestamp format

Support the timezone designator in the timestamp string according to
the ISO-8601 standard.

If no timezone designator is available, then it will be regarded as in
UTC timezone. Other valid format includes the following:
 . "Z"
 . "+/-hh", where "hh" must be 2 digits no bigger than 12;
 . "+/-hhmm", where "hh" must be 2 digits no bigger than 12 and
   "mm" should better be "00"

It's worthwhile to note that the current strptime() API implementation
has NOT fully implemented the timezone definition as in ISO-8601, for
example:
 . at most 4 digits will be consumed after the "+/-" offset character,
   moreover, if it encounters any non-digit character, it stops parsing
   the rest of timezone string;
 . the "mm" value will not always be treated as "minutes" as expected
   by user;
 . the whole timezone is ignored if "hh" value is bigger than 12

Please refer to comments in timezone_is_valid() in obix_utils.c for
details.

Although the oBIX server can handle timezone formats gracefully and
silently, the client should be notified that their provided timezone
may have not been manipulated by the oBIX server.

Also included is a test case to demonstrate all the tricks on timestamp
strings.
Fix the start boundary of a history record

"<obj " used to be regarded as the start of a history record. However,
unfortunately, with the presence of complex device contract and relevant
history record that contains sub nodes, this will simply break in that
parse_log() will mistakenly regard the beginning of a sub node in the
previous record of the desirable one as the starting point of it, resulting
segment of previous history record fetched as part of response as well.

To fix it, simply be stringent on the starting point of a history record
to be "<obj is=\"obix:HistoryRecord\">"