Refine definition of extra metadata tags

Fix potential ambiguities or issues with extra metadata:

1. original rules disallowed colons in `value`.
This is unnecessarily restrictive:
everything is whitespace separated,
so allowing colons in the value of extra metadata does not introduce
any ambiguity in parsing.

This allows extra metadata like `key:val:ue` to be
correctly parsed as the key `key` and value `val:ue`.

2. Make it clear than the value may be empty.
This was previously not defined.
Allowing an empty value is also syntactically unambiguous,
so this should be fine.

This allows an extra metadata entry like `key:`,
where the key is `key` and the value is an empty string.

3. Make it clear that the key must not be empty.
This was previously not defined.
It does not make sense for there to be an extra metadata
where the key is an empty string.
As such, entries such as `:` or `:something`
must not be parsed as extra metadata tags.

README.md

@@ -192,5 +192,6 @@ Tool developers may define additional formatting rules for extra metadata.
 
 Developers should use the format `key:value` to define additional metadata (e.g. `due:2010-01-02` as a due date).
 
-Both `key` and `value` must consist of non-whitespace characters, which are not colons. Only one colon separates the `key` and `value`.
-
+`key` must consist of one or more non-whitespace characters, which are not colons.
+`value` must consist of non-whitespace characters.
+A single colon separates the `key` and `value`.