Restructuring plugins

[k-toumura]

• [ ] Bugfix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)

Proposed changes

• Restructuring plugin mechanism:
  • All rules are provided by plugin. No built-in rules in main 'nrlint' module.
  • Consolidate small rule plugins to single 'nrlint-plugin-core' module.
  • Webpack is called in 'prepare' script so that plugin users don't need to use Webpack.
• Add test codes for Flow, Node, SubFlow in flow manipulation API.
• Bug fix.

Checklist

• [x] I have read the contribution guidelines
• [x] For non-bugfix PRs, I have discussed this change on the forum/slack team.

[k-toumura]

This PR includes a commit of PR #2. To avoid conflict, I've closed PR #2, and copied the comment to below:

---

Proposed changes

This PR enables an Editor-integrated linter function so that flow developer can validate their code on the fly.

remaining issues

• some rules in browser-side (flowsize) are manually copied from CLI version, and other rules (func-style-eslint, no-func-name) are automatically generated using Webpack. I also plan to use Babel for transpile a modern Node.js code to a code which is compatible with old browsers (IE11, etc.). Use of complex tool lowers the developer's burden (code duplication, browser compatibility issue, etc.), but it also brings complicated build process and larger dependency of other packages. We are still investigating how to write/generate browser-size code.
• http-in-resp and loop rules are not yet ported to Editor-side.
• Some GUI parts (CSS classes, etc.) are borrowed from other part of Node-RED Editor. We should use our own CSS classes.

---

[knolleary]

Given the size of this PR, I'm going to merge it as-is without doing a full review.

Following our call this week, I plan to spend time in the next few days going through this code base to see how you've approached the plugin loading. That will help inform what is needed for the main plugin design for Node-RED.

We may need to make some changes here based on the outcome of that design - but will be easier to do with follow-on PRs rather than try to manage it all under this one.