Migrate to ECMAScript Modules

Migrate the usage of CommonJS specific code and imports to ESM.  Roughly
summarised this:
- Changes all require() calls to import statement or expressions.
- Changes usage of module.exports to export statements.
- Replaces require.resolve with import.meta.resolve.
- Replaces conditional imports with conditional subpath imports.
- Replaces module === require.main with import.meta.main.
- Adds the full filename with extention to all relative imports.
- Changes all usage of __dirname and __filename to their import.meta
  equivalents.
- Sets "type": "module" in package.json files.
- Removes usage of "use strict".
- Adds .ts an an alias of .js for the webpack build.

Due to differences in how require and import resolves files the plugin
entrypoints will have to include the filename and extension after this
migration in order to work.

docs/contributing.md

@@ -229,8 +229,8 @@ Files containing and exporting a single class should be named the same as the cl
 Relative imports in lib package are prefixed with lib to make them easier to distinguish, as the names tend to be very generic.
 E.g.:
 
-    const libLink = require("./link");
-    const libLuaTools = require("./lua_tools");
+    import libLink from "./link";
+    import libLuaTools from "./lua_tools";
 
 Note that no sub-modules of the lib package is imported directly from the outside of it with the exception of `build_mod`.
 

docs/devs/json-serialisable-classes.md

@@ -14,7 +14,7 @@ See the following example code for a hypothetical `Data` class with a single pro
  * A Data class example
  * @alias module:Data
  */
-class Data {
+export class Data {
     /** @type {string} */
     member = "foo";
 
@@ -41,8 +41,6 @@ class Data {
         return json;
     }
 }
-
-module.exports = Data;
 ```
 
 Serialising an instance of `Data` for JSON is as simple as doing `serialised = JSON.stringify(data)` as the `toJSON` method is automatically called by `JSON.stringify` to create a suitable object.
@@ -53,14 +51,13 @@ For example a class holding a data property with an instance of the Data class f
 
 ```js
 // Composed.js
-"use strict";
-const Data = require("./Data");
+import Data from "./Data";
 
 /**
  * Composed data class example
  * @alias module:Data
  */
-class Composed {
+export class Composed {
     /** @type {module:Data|undefined} */
     data;
 
@@ -83,8 +80,6 @@ class Composed {
 
     // toJSON is optional and not needed for this particular class
 }
-
-module.exports = Composed;
 ```
 
 It's easy to create a new instance of Composed by calling `new Composed(new Data("spam"))` and serialising to and from JSON is the same as for Data.

docs/writing-plugins.md

@@ -48,12 +48,12 @@ By default the main entrypoint is the `index.js` file, but this may be changed b
 Here's an example of `index.js`:
 
 ```js
-module.exports.plugin = {
+export const plugin = {
     name: "foo_frobber",
     title: "Foo Frobber",
     description: "Does advanced frobnication",
-    instanceEntrypoint: "instance",
-    controllerEntrypoint: "controller",
+    instanceEntrypoint: "instance.js",
+    controllerEntrypoint: "controller.js",
     messages: {
         /* See below */
     },
@@ -117,9 +117,9 @@ The plugin class should derive from its respective base class defined in `lib/pl
 For example, to define a ControllerPlugin class the following code can be used:
 
 ```js
-const { BaseControllerPlugin } = require("@clusterio/controller");
+import { BaseControllerPlugin } from "@clusterio/controller";
 
-class ControllerPlugin extends BaseControllerPlugin {
+export class ControllerPlugin extends BaseControllerPlugin {
     async init() {
         this.foo = 42;
         await this.startFrobnication();
@@ -127,10 +127,6 @@ class ControllerPlugin extends BaseControllerPlugin {
 
     // ...
 }
-
-module.exports = {
-    ControllerPlugin,
-}
 ```
 
 For the instance plugin it's exactly the same except "Controller" is replaced with "Instance", for host plugins "Host" is used and for the clusterioctl plugin "Ctl" is used.
@@ -525,7 +521,7 @@ In its simplest form collecting data from plugins consists of defining the metri
 For example:
 
 ```js
-const { Counter } = require("@clusterio/lib");
+import { Counter } from "@clusterio/lib";
 
 const fooMetric = new Counter(
     "clusterio_foo_frobber_foo_metric", "Measures the level of foo",
@@ -541,7 +537,7 @@ It's recommended that plugin metrics follow `clusterio_<plugin_name>_<metric_nam
 For metrics that are per-instance, you must define an `instance_id` label and set it accordingly, for example:
 
 ```js
-const { Counter } = require("@clusterio/lib");
+import { Counter } from "@clusterio/lib";
 
 const barMetric = new Gauge(
     "clusterio_foo_frobber_bar_metric", "Bar instance level",
@@ -565,7 +561,7 @@ The control entrypoint for plugins allows you to extend clustectl with your own
 The creation of custom commands typically starts with defining a command tree for the plugin:
 
 ```js
-const { Command, CommandTree } = require("@clusterio/lib");
+import { Command, CommandTree } from "@clusterio/lib";
 const fooFrobberCommands = new CommandTree({
     name: "foo-frobber", description: "Foo Frobber Plugin commands"
 });
@@ -574,7 +570,7 @@ const fooFrobberCommands = new CommandTree({
 Then commands are added to the the plugin's command tree:
 
 ```js
-const info = require("./info");
+import { messages } from "./index.js";
 
 fooFrobberCommands.add(new Command({
     definition: ["frobnicate <type>", "Do frobnications", (yargs) => {
@@ -600,15 +596,11 @@ Note that messages sent from clusterioctl needs to have `"control-controller"` a
 To have the command tree become part of clusterioctl it needs to be added to the rootCommand tree in `addCommands` callback of the Ctl plugin:
 
 ```js
-const { BaseCtlPlugin } = require("@clusterio/ctl");
+import { BaseCtlPlugin } from "@clusterio/ctl";
 
-class CtlPlugin extends BaseCtlPlugin {
+export class CtlPlugin extends BaseCtlPlugin {
     async addCommands(rootCommand) {
         rootCommand.add(fooFrobberCommands);
     }
 }
-
-module.exports = {
-    CtlPlugin,
-}
 ```