Stop using ckeditor-boilerplate

[Reinmar]

That's another post mortem related to #117 and #2.

Initially we had the approach that we merge https://github.com/ckeditor/ckeditor-boilerplate into each repository that we create. It seemed right, as saying that each our repository inherits from the boilerplate. Unfortunately, it turned to be a problem.

1. Merging boilerplate into other repositories was closing issues in these repositories. That's due to how GH handles commits with "Fixes #xxx.".
2. Theoretically, having the boilerplate as one of the remotes was allowing us to quickly update the files which the boilerplate brings by simply merging it again. In practice, we had lots of conflicts in files for which the boilerplate contains only templates, so which were later edited.
3. Doing the upgrade from boilerplate manually was super irritating and time consuming so we'll need to develop tasks for automating this job (the dev tasks already contain some ground and Running task on all subrepositories ckeditor5#41 will enable the rest). Some tasks can be fully automated like updating license headers or JSCS/JSHint configs or dependencies in package.json, but some will need to be totally specialised in their one time job. Most of them cannot be performed by merging changes from the boilerplate.

Therefore, we decided to stop using the boilerplate repo. All tasks' code and templates are now kept in https://github.com/ckeditor/ckeditor5 and is used to create new packages. It can also be later used to upgrade the other packages, once we have #41 and related tasks.

The issue right now is that the linting tasks repeat in each repo (plus we have more dependencies in repos' package.json files). We can consider moving this code out to a ckeditor5-dev-tasks and handling this as a separate dependency. This will remove many dependencies from package.json and simplify upgrades even further.

[Reinmar]

So the question is – do we want to move the dev/tasks/lint and eventually also some generic task tools to a separate package?

Note: I do not propose to move also the other tasks (build, dev and in the future other ones) which in the current state can only work in the main repo and which have a lot of dependencies which would significantly slow down installing packages in the dev mode.

[Reinmar]

BTW. As for automatically upgrading dependencies, we can use http://greenkeeper.io/ once we have the CI ready. This should work most of the time, failing only when linters (JSHint and JSCS) introduce some backward incompatible change in their settings or find some previously missed mistakes. Those situation will require upgrading their configuration, what can be automated by main repo's dev tasks, because all repositories should share exactly the same settings.

[Reinmar]

We're not using the boilerplate any more. It was not worth the effort. The packages should be as simple as possible anyway.