Add generic member_data to simplify operator governance

[eddyashton]

As described in #1597.

This adds a member_data field for each member, in the same pattern as user_data, storing arbitrary JSON for the governance scripts to interpret how they wish. operator_gov.lua is updated to use this, creating an object with is_operator = true for operating members, rather than hardcoding them in the constitution.

#1597 mentioned exposing the proposer's ID to the constitution, but I don't think this is actually necessary. We don't currently block proposals on any grounds, so we'd have to add that if we wanted to gate the creation of specific proposals to members/non-members. Instead we care about the operatoricity of each voter. In the case of proposals submitted by operators (which are freely submitted like any other members'), their single yes vote is sufficient to pass an 'operator proposal' (one of the constitution-defined calls), but this works purely by vote-iteration and doesn't need to consider the proposer separately.

[ghost]

member_data@13193 aka 20200928.14 vs master ewma over 50 builds from 12648 to 13190