Standardization cannot parse input with micro- or nanoseconds

[benedeki]

Describe the bug

The pattern for timestamp parsing does not allow to handle micro-/nanoseconds.

To Reproduce

Input values of the following type (common output from many DBs) cannot be Standardized to timestamp:
"21-MAR-2019 19:00:00.223001"

Expected behaviour

The input can be handled. at least with loss of precision.

Possible solutions

• Keyword for this type, (like epoch) able to handling it
• own pattern placeholders (u for microseconds, n for nanoseconds), where the result looses precision to milliseconds (internally use SSS pattern placeholder after trimming the extra digits
• udf able of better casting (hint for solution)

Related issues

#465
#380

[benedeki]

The basic logic of the solution is, that the the pattern is checked for the presence of milli-, micro- and/or nanoseconds. If not found, nothing special is needed.
If present their location is identified withing the pattern (class `Section'), The parsing is then done in two steps:

1. The second fractions parts are removed both from the pattern and source and parsed - this is a timestamp with seconds precision
2. The fractions are extracted from the source and divided to be the appropriate decimal value of a second; then added to the timestamp.
   Unfortunately there are complications, I failed to take into account and discovered during testing. See bug If Timestamp/Date pattern contains both literal or variable length entry and fractions of second placeholders it's likely to cause error #677. Still this enhances the current possibilities of parsing, the errors are kind of corner-cases. Therefore I think this is worth to include, despite the known bug.

Btw, epochmicro and epochnano added as well. Furthermore, they don't have to be whole numbers only, can be decimal.