Add location access control to config class

Add a per field access parameter to the config class which specifies
which of master, slave and control can access the given field.  A
location is added to the config class to specify which party owns it and
fields which do not have an access parameter are not present in the
config and will throw if attempted to be read from or writen to.

The serialize, load, update, get, set and setProp are ammended with a
location parameter which specifiy where the data is from or destined to
and the access checks are performed to ensure remote access to the
config is still limited by the access parameter of field.

With this system in place the master config can be shared with control
and slave connections without compromising secrets that should stay
private.  This is primarily the master authentication secret, but other
plugins may define secrets it does not want to have shared with slave
and/or control connections.

docs/config-system.md

@@ -28,6 +28,16 @@ after the groupName have been set and before the class has been
 finalized.  The `define` method takes an object as argument with the
 following properties:
 
+**access**:
+    The locations this config field can be read and modified from.  This
+    is an array of strings which can contain the values `"master"`,
+    `"slave"` and `"control"`.  If a party is missing in this array then
+    that party will not receive the value of this field when the config
+    is shared, and will be unable to modify the field.  Takes the value
+    of `defaultAccess` set on the config group class if not passed.
+    Note that instance config groups should have both `"master"` and
+    `"slave"` for all of its fields or unexpected behaviour may occur.
+
 **type**:
     The type of config value this field will support.  The supported
     values are boolean, string, number, and object, and if an attept is

docs/writing-plugins.md

@@ -224,12 +224,13 @@ but for event handlers registered on EventEmitters it's critical that
 exceptions are catched and handled appropriately.
 
 
-Defining Configuration
-----------------------
+Plugin Configuration
+--------------------
 
 Clusterio provides a configuration system that handles storing,
 distributing, editing and validating config fields for you.  You can
-take advantage of it by subclassing `PluginConfigGroup`, setting the
+take advantage of it by subclassing `PluginConfigGroup`, setting
+`defaultAccess` to where config entries can be accessed from, setting the
 `groupName` to your plugin name, defining fields on it, finalizing it,
 and passing it as either `MasterConfigGroup` or `InstanceConfigGroup` in
 the `info.js` export.  For example in info.js:
@@ -237,6 +238,7 @@ the `info.js` export.  For example in info.js:
     const libConfig = require("@clusterio/lib/config");
 
     class MasterConfigGroup extends libConfig.PluginConfigGroup { }
+    MasterConfigGroup.defaultAccess = ["master", "slave", "control"];
     MasterConfigGroup.groupName = "foo_frobber";
     MasterConfigGroup.define({
         name: "level",
@@ -261,7 +263,7 @@ for example in the MasterPluginClass:
     }
 
 The same applies for instance configs, replace "master" with "instance"
-where appropriate.  See [Configuration System](configuration-system.md)
+where appropriate.  See [Configuration System](config-system.md)
 for more details on how this system works.