Implement acceptance of custom file extensions for files to validate

[sdruskat]

This pull request adds the following cli options:

• -y EXT, --yaml-extension EXT
• -j EXT, --json-extension EXT

Both accept a string representing a file extension for files like, e.g., my-data-file.ext which contain JSON or YAML data respectively, but don't share the default file endings.

Usage examples:

pykwalify -d my-json-data-file.jext -s schema.yml -j jext
pykwalify -d my-yaml-data-file.yext -s schema.yml -y yext

[coveralls]

Coverage increased (+0.04%) to 87.241% when pulling d0fa7a3 on sdruskat:pykwalify into e7fac6a on Grokzen:master.

[coveralls]

Coverage increased (+0.04%) to 87.241% when pulling 54d967b on sdruskat:pykwalify into e7fac6a on Grokzen:master.

[coveralls]

Coverage increased (+0.04%) to 87.241% when pulling 54d967b on sdruskat:pykwalify into e7fac6a on Grokzen:master.

[coveralls]

Coverage increased (+0.04%) to 87.241% when pulling 54d967b on sdruskat:pykwalify into e7fac6a on Grokzen:master.

[coveralls]

Coverage increased (+0.04%) to 87.241% when pulling 6622b08 on sdruskat:pykwalify into e7fac6a on Grokzen:master.

[Grokzen]

@sdruskat Just a random thought. Why not just remove the blocks that is in place right now to only support .yaml/.json filetypes? Why not just accet any file that you can point to and try to read it either as json or yaml? This feels like a wrong turn somewhere to add another flag to allow more file endings, the cli syntax feels clunky and not correct in some way.

I see no reason right now to merge this MR. Simply allowing any file extension and handle the loading error seems easier.

[dhimmel]

Simply allowing any file extension and handle the loading error seems easier.

Isn't JSON a subtype of YAML? Hence perhaps you'll always be able to read every file using using the YAML parser? Is it ever necessary to fallback to the JSON parser assuming a YAML parser is installed?