Query for unsupported properties

[EdwardHinkle]

This is a branch off of #8 (comment), where that issue is focused on hiding client supported UI fields that a server doesn't support.

This issue is about helping a Micropub client add support for properties that they don't support (yet). The hope is that overtime the client would add customized support for each property, but this would help build a bridge while properties are experimental and allow for people to customize their software a bit more.

Use Cases:
There are some properties that have large server support but not much client support such as: visibility, post-status and location-visibility. This would allow a user who has a server that supports those and finds those necessary properties to be able to use any Micropub client that supports this functionality.

Also, there are cases where a server has custom properties. For example, my server, abode, has the idea of channels. This likely will never be a property that a large number of servers use and thus will never officially become supported. But causes me to either have to not use certain Micropub clients or overloading the syndication behavior to essentially do things that aren't syndication such as apply a channel to the post.

[EdwardHinkle]

Rather than a separate query, this is likely just an extension of the Supported Properties query

[EdwardHinkle]

The initial brainstorm on #8 needed some refinement based on various UI libraries, etc. I've modified it based on feedback from @grantcodes as well as looking at UI libraries. Below the new version for discussion/iteration/destruction:

properties: [
  {
    "uid": "visibility",
    "name": "Visibility",
    "predefined": true,
    "multiple": false,
    "default": "private", 
    "options": [
      {
         "uid": "public",
         "name": "public"
      },
     {
         "uid": "private",
         "name": "private"
      },
     {
         "uid": "unlisted",
         "name": "unlisted"
      }
    ]
  },
  {
    "uid": "categories",
    "name": "Tags",
    "predefined": false,
    "multiple": true,
    "default": [],
    "optionsQuery": "categories" // This is the query sent (?q=categories) to retrieve the options
  },
  {
    "uid": "syndicate-to",
    "name": "Syndication",
    "predefined": true,
    "multiple": true,
    "default": [],
    "options": [
      {
        "uid": "uid of object",
        "name": "display name of object"
      },
      {
        "uid": "twitter-service",
        "name": "Twitter Username"
      },
     {
        "uid": "github-service",
        "name": "GitHub Username"
      },
    ]
  }
]

There are a couple notable changes and things to think through about this model.
I changed it from being a dictionary object to an array of objects with uid being the property id. This is based on looking at other Micropub queries and approaches. It's better for everything in Micropub to use similar approaches.

name is the user facing label just like the Query for Supported Vocabulary.

predefined isn't the best name, but it's the idea whether you can send ANY value or only the ones chosen by the server.

multiple is boolean because in reality a field is either going to be single choice or unlimited.

default could either be ALWAYS an array or it could mirror the multiple attribute. I kind of feel like if multiple is false, default should be a string of the uid from the options. But if it simplifies things, I'm not opposed to it always being an array and if multiple is false, then the client grabs index 0 of default.