hot-reload/incremental build JSON language files

[jngbng]

breaking change:
path option is deleted and users should load language JSON files using
gatsby-source-filesystem then load it using GraphQL query.

fix #4

[jdtzmn]

@jngbng can we display a warning that the path config is deprecated in the onCreateNode handler? Also, wouldn't a breaking change warrant incrementing the major version, as the semantic versioning guidelines suggest? Otherwise, users might unintentionally update to the breaking change.

I'd also like to thank you once again for your work on this. It is much appreciated!

[jngbng]

@jdtzmn Thanks for good suggestion. The maintainer will pick the version when releasing to NPM as this project manages version using release-it tool. He/she should edit README.md in my PR, though.

Displaying a warning is a good idea! But onCreateNode handler seems not a good place to print a warning as it is called frequently and will cause excessive warnings. (That may be what we want, thought.) Since I am new to Gatsby plugin api, I have no idea of the best place. Another option would be post install hook of this package. (like core-js) Any suggestions are welcomed.

[jdtzmn]

@jngbng Makes sense. I was reviewing the PR and I saw the section in the README.md and figured I should mention it.

I found the following issue that addresses where to display deprecation warnings:
gatsbyjs/gatsby#6974

They recommend using the onPreBootstrap handler.

[jngbng]

@jdtzmn Thanks for your suggestion. Now plugin prints an error message when deprecated "path" option still exists in plugin option.

[jdtzmn]

@jngbng Love it! Looks great. I think it's ready for @jimmyn to review.

[jimmyn]

I will check it asap, thanks for your contribution

[jimmyn]

If we are moving back to graphql we should also support loading namespaces separately. This is actually what I wanted to implement next and I need it myself. If it is a big page with lots of translation it does not make sense to load those translations on other pages but at the same time, you can have common translations for header, for example.

Is it going to work with a query like this:

query($language: String!) {
    locales: allLocale(filter: {lng: {eq: $language}, ns: {regex: "/(common|about)/"}}) {
      edges {
        node {
          ns
          data
          lng
        }
      }
    }
  }

Ideally, we should simplify it somehow or at least document

Another thing is that the language variable is inconsistent across the code
We now have language, lang, lng. I get that lng is shorter but I'd prefer consistency

[jngbng]

@jimmyn Yes, it works as you mentioned. I added sections for it on README.md. c40fcb1

Also changed lang, lng to language.