Add workflow validation

Nobody has claimed this yet.

Ensure the workflow has the correct syntax.

#### Top-level fields
- [x] A State Machine MUST have an object field named "States", whose fields represent the states.
- [x] A State Machine MUST have a string field named "StartAt", whose value MUST exactly match one of names of the "States" fields. The interpreter starts running the the machine at the named state.

#### States
- [x] The state name, whose length MUST BE less than or equal to 80 Unicode characters, is the field name
- [x] State names MUST be unique within the scope of the whole state machine. (NOTE JSON.parse() only returns the last entry)
- [x] All states MUST have a "Type" field. This document refers to the values of this field as a state’s type, and to a state such as the one in the example above as a Task State.
- [x] Any state except for Choice, Succeed, and Fail MAY have a field named "End" whose value MUST be a boolean. The term "Terminal State" means a state with with { "End": true }, or a state with { "Type": "Succeed" }, or a state with { "Type": "Fail" }.

#### Transitions
- [x] All non-terminal states MUST have a "Next" field, except for the Choice State. The value of the "Next" field MUST exactly and case-sensitively match the name of another state.
- [x] Choice "Default" MUST match the name of another state.
- [x] Choice Choices MUST have a "Next" field that MUST match the name of another state.

#### Timestamps
- [ ] These are strings which MUST conform to the [RFC3339](https://www.ietf.org/rfc/rfc3339.txt) profile of ISO 8601, with the further restrictions that an uppercase "T" character MUST be used to separate date and time, and an uppercase "Z" character MUST be present in the absence of a numeric time zone offset, for example "2016-03-14T01:59:00Z".

#### Data
- [ ] The interpreter passes data between states to perform calculations or to dynamically control the state machine’s flow. All such data MUST be expressed in JSON.
- [ ] As each state is executed, it receives a JSON text as input and can produce arbitrary output, which MUST be a JSON text.

#### Reference Paths
- [ ] all Reference Paths MUST be unambiguous references to a single value, array, or object (subtree).

#### Payload Template
- [ ] A Payload Template MUST be a JSON object; it has no required fields. (I believe this is covered already)
- [x] If the field value begins with only one "$", the value MUST be a Path.
- [x] If the field value begins with "$$", the first dollar sign is stripped and the remainder MUST be a Path
- [ ] If the field value does not begin with "$", it MUST be an Intrinsic Function (see below)
- [ ] A JSON object MUST NOT have duplicate field names after fields ending with the characters ".$" are renamed to strip the ".$" suffix. (I believe this is covered already)

#### Intrinsic Functions
- [ ] An Intrinsic Function MUST be a string.
- [ ] The Intrinsic Function MUST begin with an Intrinsic Function name.
- [ ] An Intrinsic Function name MUST contain only the characters A through Z, a through z, 0 through 9, ".", and "_".
- [ ] The Intrinsic Function name MUST be followed immediately by a list of zero or more arguments, enclosed by "(" and ")", and separated by commas.
- [ ] Intrinsic Function arguments may be strings enclosed by apostrophe (') characters, numbers, null, Paths, or nested Intrinsic Functions.
- [ ] The following characters are reserved for all Intrinsic Functions and MUST be escaped: ' { } \

Start by locating the existing workflow validation entry point in the Ruby implementation and review how the checked requirements are handled. Use the unchecked Amazon States Language sections as the scope, including RFC3339 timestamps, JSON data, reference paths, payload templates, and intrinsic functions. Done means the remaining requirements are validated with appropriate tests.

Written by the indexing model from the issue text.