return public_key for clients in all cases

To be consistent with the open-source API and tools that are depending
on it, we should always return public keys with client objects instead
of certificates. The following is a situation that we've recently
encountered:

  * consumer of API switches on the response having json_class field
  * response inflates to a Chef::ApiClient if json_class is set
  * if inflated, consumer expects the public_key field to be set
  * if not inflated (no json_class), consumer expects certificate
    field to be set

This commit ensures that we always set both json_class and
public_key, the combination that the Ruby chef-client code expects.
chef_client: add tests for converting certs to public keys
chef_client: prefer public key over certificate
Add json_class and chef_type to default field values to maintain consistiency with OSC and the rest of the EC changes.
Clear certificate field out of json when we are regenerating a public
key.

This is to fix a bug when we reset a cert to a public key.

After keygen was commited we encountered a bug where we'd reset the
key, set the json to have a public_key field from that reset key, but
fail to clear the cert field. Later, we'd pull the cert in preference
to the public key when updating the record. This would cause the
record to match the old one, and we'd not actually update anything in
the database. However we'd still return both the public key and the
certificate. Unlucky users would pull the private key and assume their
client had been rekeyed, when it hadn't.
Merge pull request #77 from opscode/ma/fix_cert_remnant

Clear certificate field out of json when we are regenerating a public key