Restrict target_keys object to contain only a single key value pair.

[annakrystalli]

This PR resolves #117 by restricting target_keys objects to contain only a single key value pair.

Successful validation is demonstrated in hubAdmin PR hubverse-org/hubAdmin#90 and more specifically in these tests using this and this test file.

Question

Should we also remove target_variable and target_outcome from the schema? These were originally added as standard task ids (and are documented as such in hubDocs) for the following reason:

target_variable/target_outcome: task IDs making up unique identifiers of a two-part target. These tasks can be used in hubs that want to divide the definition of a target across two variables. Both task IDs will be specified as target keys in the target_metadata array.

The answer also therefore has implications on hubverse-org/hubDocs#226

[elray1]

The content of this PR looks good to me.

I'm commenting here rather than approving because:

• There is a bit of an unresolved question for me about whether we're going to treat this as a minor version update or a major version update. I think that in the formal sense of semantic versioning, this is probably a major version update because if a hub had been using multiple target keys, they could not simply update to a schema version with this change without breaking. But if there are no existing hubs using multiple target keys, the point is moot and it seems fine to go ahead with the minor version update.
• The process we discussed in a hubverse devteam meeting a few weeks ago was that we'd email the hubverse mailing list to describe this planned change and check in with existing hubs to see if anyone was using multiple target keys before going through with it (we don't know of anyone who is). I expect that we will do this, but don't want to preempt that process.

[annakrystalli]

Although I don't believe anyone is indeed using multi column target format, the more I thought about this, the more I felt we should err on the side of correct versioning and signify a breaking change through a v5.0.0 schema. Versioning also acts as historical record of breaking changes and I think for correctness we should adhere to it. If you agree, I'll go ahead and make the necessary changes first thing on Wednesday

[elray1]

r.e. using a major schema version, seems fine to me

[zkamvar]

Approved pending the bump to v5. The community has been made aware of these changes and there have not been any comments, so it's good to go.

Should we also remove target_variable and target_outcome from the schema?

I think that would be a good idea. Reducing complexity is always a plus.