Feature/granular member privacy (#174)

* Some reasons this needs to exist for it to run on my machine? I don't think it would hurt to have it in other machines so

* Add options to member model

* Add Privacy to member embed

* Added member privacy display list

* Update database settings

* apparetnly this is nolonger needed?

* Fix sql call

* Fix more sql errors

* Added in settings control

* Add all subject to system privacy

* Basic API Privacy

* Name privacy in logs

* update todo

* remove CheckReadMemberPermission

* Added name privacy to log embed

* update todo

* Update todo

* Update api to handle privacy

* update todo

* Update systemlist full to respect privacy (as well as system list)

* include colour as option for member privacy subject

* move todo file (why was it there?)

* Update TODO.md

* Update TODO.md

* Update TODO.md

* Deleted to create pr

* Update command usage and add to the command tree

* Make api respect created privacy

* Add editing privacy through the api

* Fix pronoun privacy field in api

* Fix info leak of display name in api

* deprecate privacy field in api

* Deprecate privacy diffrently

* Update API

* Update documentation

* Update documentation

* Remove comment in yml

* Update userguide

* Update migration (fix typo in 5.sql too)

* Sanatize names

* some full stops

* Fix after merge

* update migration

* update schema version

* update edit command

* update privacy filter

* fix a dumb mistake

* clarify on what name privacy does

* make it easier on someone else

* Update docs

* Comment out unused code

* Add aliases for `member privacy all public` and `member privacy all private`

docs/2-user-guide.md

@@ -438,7 +438,7 @@ To update your system privacy settings, use the following commands:
 
     pk;system privacy <subject> <level>
     
-where `<subject>` is either `description`, `fronter`, `fronthistory` or `list`, corresponding to the options above, and `level` is either `public` or `private`.
+where `<subject>` is either `description`, `fronter`, `fronthistory` or `list`, corresponding to the options above, and `<level>` is either `public` or `private`. `<subject>` can also be `all` in order to change all subjects at once.
 
 For example:
 
@@ -449,15 +449,37 @@ For example:
 When the **member list** is **private**, other users will not be able to view the full member list of your system, but they can still query individual members given their 5-letter ID. If **current fronter** is private, but **front history** isn't, someone can still see the current fronter by looking at the history (this combination doesn't make much sense).
 
 ### Member privacy
-There is also an option to mark a specific member as private, using the command:
+There are also nine options for configuring member privacy;
 
-    pk;member <name> private
+- Name
+- Description
+- Birthday
+- Pronouns
+- Colour
+- Date created
+- Message count
+- Visibility
 
-A private member will *not* be displayed in member lists (even if the member list is public), and will show only limited information if looked up by others - namely name, display name and avatar. Other information, such as description, pronouns and birthday will be hidden.
+As with system privacy, each can be set to **public** or **private**. The same rules apply for how they are shown too. When set to **public**, anyone who queries your system (by account or system ID, or through the API), will see this information. When set to **private**, the information will only be shown when *you yourself* query the information. The cards will still be displayed in the channel the commands are run in, so it's still your responsibility not to pull up information in servers where you don't want it displayed.
 
-All of this can only be accessed using the member's 5-letter ID, which is exposed when proxying. So, if you want to keep a member absolutely private, it's recommended you don't proxy with it publicly - that way the ID isn't exposed.
+However there are two catches. When name is set to private, it will be replaced by a members display name, but only if they have one! When visibility is set to private, the member will not show up in the member list unless -all is used in the command (and you are part of the system).
+
+Member info will not be shown in member lists even if someone in the system queries the list, unless the user is part of the system and uses the -all flag.
+
+To update a members privacy you can use the command:
+
+    member <member> privacy <subject> <level>
+
+where `<member>` is the name or the id of a member in your system, `<subject>` is either `name`, `description`, `birthday`, `pronouns`, `color`, `metadata`, or `visiblity` corresponding to the options above, and `<level>` is either `public` or `private`. `<subject>` can also be `all` in order to change all subjects at once.  
+`metatdata` will affect the message count, the date created, the last fronted, and the last message information.
+
+For example:
+
+    pk;member John privacy visibility private
+    pk;member "Craig Johnson" privacy description public
+    pk;member Robert privacy color public
+    pk;member Skyler privacy all private
 
-An example of a private member is `cmpuv` - try looking it up and see what's shown, as well as the corresponding system list (`pk;system exmpl list`).
 ## Moderation commands
 
 ### Log channel