fix: Add error handling when parsing JSON/YAML spec

[inFocus7]

Resolves: #355

Context

When testing a YAML setup similar to the one added in the test, I noticed no errors were reported and any invalid spec was ignored. While it's not a breaking behavior, it could lead to missing configuration without noticing.

Fix

To fix this we simply should not ignore any errors when parsing.

Open Questions (from me)

• Does bypass make sense to use as the gate for ignoring (or not) the errors?
  • Should we never ignore these errors?
  • Or should we add a new field specifically for this to lessen possibility of breaking users existing environments?
    • Adding this as a possible path forward as the unit tests fail when not ignoring errors, so it may make sense to have another parameter/option.

Concerns (from me)

• This could technically be breaking. Users with invalid configurations - those caught by the Decode & Marshal methods - would now receive errors.
  • This breakage may be avoidable if instead of returning the error when caught, we store/save it until the final return specInfo, nil, where we'd return any error.

[inFocus7]

interesting:

--- FAIL: TestDocument_Paths_As_Array (0.00s)
panic: cannot create new document: &{%!e(string=invalid character ':' after array element) %!e(int64=53)} [recovered]

i'm guessing this is due to an error occurring when parsing the json as it is not valid (at least according to the library). So the paths forward I see are either:

1. Live with not catching errors during parsing (essentially removing the need for this issue + pr)
2. Use another field similar to bypass for these errors, defaulting to false so it's not breaking, and noting the limitations of it.
   • I'm not certain if or where in json []map is used, and if it's a special case we support, or if it's valid json but the library doesn't know it.