Merging v1.0-rc3 into master

See merge request !6

Merging v1.0-rc2 into master

See merge request !5

Add text in sec 4 describing where CRS objects appear

See merge request !4

Modify the prescription for time_origin format

See merge request !3

It turns out that the DALI prescription for ISO-8601-like timestamps
is not quite suitable here since it can't cope with dates BCE,
so the time_origin value for time_coords_id='jd' in Appendix B
would not be compatible.

So remove reference to DALI and just present a pattern that should
be comprehensible to readers, with a vague reference to ISO8601.

I have also removed the (optional) 'Z' timezone indicator;
DALI says "Astronomical values never include a time zone indicator",
allowing Z only for "civil" dates (see DALI v1.1 sec 3.3.3).

Finally I removed the optional ".000" from the predefined values,
since they don't provide much value.  Users can still supply
fractional seconds if they want to, as should be clear from the examples.

Suggestions to improve CRS section

See merge request !2

Modify Section 4 (Coordinate Reference System) so that the Local CRS
(the only one recommended) comes first and the other two,
Linked and Named (not recommended) come afterwards.
The previous sequence was Linked (not recommended), Local (recommended),
Named (not recommended) which seemed unnecessarily confusing.

(An alternative would be to drop the two sections on non-recommended
CRS variants altogether).

Also adjust the structure of the Named CRS section to match that
of the Linked CRS section (separate numbered subsection on the
properties object), fix a couple of typos where the wrong CRS
type was written. and adjust capitalisation to be consistent.

Finally remove the sentence "The TimeCoords reference position is
defined in the RefPosition property of the CRS." which looks like
it was left over from an earlier version, since RefPosition has
been replaced by ref_position_id whose use is explained elsewhere.

Fix some errors in the draft spec.

See merge request !1

According to RFC7946 section 3.1.6, GeoJSON polygon hole vertices
MUST be specified in a clockwise direction.
Fix the examples in A.3 and A.6 to follow these rules.