fix: remove json indirection, restructure package

[craigfurman]

Why?

Extracting parsers that are used in several repos to this shared library makes a lot of sense! But, before we roll this out further (e.g. https://github.com/snyk/cloud-config-policy-engine/pull/379 and similar PRs), I want to take the opportunity to raise 2 issues, which I've attempted to fix in this PR:

First, the repository structure is unidiomatic. "pkg" is often found in the middle of a go subpackage hierarchy, but never at the end. This repo is already called "snyk-iac-parsers", so why not put parsers at the top level? Then, import declarations like parsers "github.com/snyk/snyk-iac-parsers/pkg" can simply become "github.com/snyk/snyk-iac-parsers", and the parsers package alias should be inferred automatically from this repo's package declarations.

Secondly, the JSON parser isn't really reusable: all it does is wrap errors with pkg/errors. Wrapping errors is application-specific, hence why we had the ParseJSON function in policy-engine in the first place, but putting it in this shared library isn't worth the mental overhead of indirection IMO. I'd advocate for updating all places that call parsers.ParseJSON to simply call json.Unmarshal from the stdlib, which has the same signature, and apply whatever error wrapping the application in question is doing.

What do you think of this? If this is agreed and merged, let's take the opportunity to update the consumers now too. It's better to do these annoying structural changes early while it's relatively cheap! I don't think we need to worry about proper semver for the release tag, this library is pre-1.0 and not used by anyone except us.

Changelog

fix: remove existing DS_Stores

They're already gitignored, but these must have made it into the repo
before that.

fix: remove JSON parser

The json parser just wraps the stdlib json parser with pkg/errors. This
isn't worth the indirection and dependency management: error wrapping
and structure is application-specific anyway, and a poor candidate for a
library.

fix: make directory structure more idiomatic

"pkg" is an idiomatic name for the middle part of a go package's path,
but is an unusual ending. This is already a parsers library and as far
as I know there is no expected need to house many disparate sibling
packages in here, so let's just use the top level.

Move test fixtures into the client package's testdata dir, as is also
idiomatic in go.

[CLAassistant]

All committers have signed the CLA.

[craigfurman]

@teodora-sandu and I chatted about this on slack. @muratcelep, would you mind reviewing this? See justification in the "why?" section.

[craigfurman]

I'm only hesitating on the CLA because I'm not sure it makes sense, given I'm an org member! Should I sign it?

[muratcelep]

@craigfurman lgtm!

[teodora-sandu]

I think every time we add a new CLA we need to sign it - I've definitely signed it every time I created a new public repo @craigfurman