Add test targeting BZ 1151240

Some API responses contain a list of IDs, and others contain a list of hashes.

For example, a GET request to `/gpgkeys/:id` returns data in this format:

    {u'name': u'foo', u'organization': {u'name': u'ACME', u'label': '...'}}

No organization ID is listed. This means that it is impossible to discover what
organization this GPG key belongs to except by issuing a follow-up search to the
`/organizations` URL (and hopefully coming up with only one result).

As a second example, a GET request to `/architectures/:id` returns data in this
format:

    {
        u'name': u'i386',
        u'operatingsystems': [
            {u'id': 1, u'name': u'rhel65'},
            {u'id': 2, u'name': u'rhel7'},
        ]
    }

This is awkward. In this case, the client can compile a list of associated
operating systems by iterating through the returned hashes and fetching through
their IDs. It is much easier to deal with a straight list of IDs:

    {u'name': u'i386', u'operatingsystem_ids': [1, 2]}

The API should return either an ID or a list of IDs for all foreign key
relationships. Client code can be simple and straightforward if a list of IDs is
returned.
Merge pull request #1545 from Ichimonji10/bz-1151240

Add test targeting BZ 1151240