Delete top-level `package.json`

Advantages of a top-level `package.json`:
  * It prevents npm from printing benign warnings about missing
    `package.json` whenever a plugin is installed.
  * Semantically, it is "the right thing to do" if plugins are to be
    installed in the top-level directory. This avoids violating
    assumptions various tools make about `package.json`, which makes
    it more likely that we can easily switch to a new version of npm
    or to an npm alternative.

Disadvantages of a top-level `package.json`:
  * Including a dependency of `ep_etherpad-lite@file:src` in the
    top-level `package.json`, which is required to keep npm from
    deleting the `node_modules/ep_etherpad-lite` symlink each time a
    package is installed, drastically slows down plugin installation
    because npm recursively walks the ep_etherpad-lite dependencies.
  * npm has a horrible dependency hoisting behavior: It moves
    dependencies from `src/node_modules/` to the top-level
    `node_modules/` directory when possible. This causes numerous
    mysterious problems, such as silent failures in `npm outdated` and
    `npm update`, and it breaks plugins that do
    `require('ep_etherpad-lite/node_modules/foo')`.

Right now, with npm v6.x, eliminating the disadvantages is far more
valuable than keeping the advantages. (This might change with npm
v7.x.)

For a long time there was no top-level `package.json` and it worked
fairly well, although users were often confused by npm's benign
warnings. The top-level `package.json` was added because we needed a
place to put ESLint config for the stuff in `bin/` and `tests/`, and
we wanted the advantages listed above. Unfortunately we were unaware
of the disadvantages at the time. The `bin/` and `tests/` directories
were moved under `src/` so we no longer need the top-level
`package.json` for ESLint.

An alternative to a top-level `package.json`: Create
`plugins/package.json` and install all plugins in `plugins/`. If
`plugins/package.json` has a dependency of
`ep_etherpad-lite@file:../src` then plugin installation will still be
slow (npm will still recursively walk the dependencies in
`src/package.json`) but it should avoid npm's nasty dependency
hoisting behavior. To avoid slow plugin installation we could create a
lightweight `etherpad-pluginlib` package that Etherpad plugins would
use to indirectly access Etherpad's internals. As an added bonus, this
intermediate package could become an adaptor that provides a stable
interface to plugins even when Etherpad core rapidly evolves.

.gitignore

@@ -15,8 +15,8 @@ npm-debug.log
 credentials.json
 out/
 .nyc_output
-./package-lock.json
 .idea
+/package-lock.json
 /src/bin/abiword.exe
 /src/bin/convertSettings.json
 /src/bin/etherpad-1.deb

package.json

@@ -1,8 +0,0 @@
-{
-  "dependencies": {
-    "ep_etherpad-lite": "file:src"
-  },
-  "engines": {
-    "node": "^10.17.0 || >=11.14.0"
-  }
-}