Fix crashes when "id" is not a string.

[richardm-stripe]

Summary

This PR makes

$obj = StripeObject::constructFrom(['inner' => ['id' => ['foo' => 'bar']]]);

no longer crash. Sometimes "id" doesn't mean "identifier", sometimes it means "indonesia".

Detail

Right now, StripeObject::__construct is called from two important paths.

1. It's called from StripeObject::constructFrom, like this:

    public static function constructFrom($values, $opts = null)
    {
        $obj = new static(isset($values['id']) ? $values['id'] : null);

2. It's called from ApiOperations::Retrieve::retrieve, like this:

    /*
     * @param array|string $id the ID of the API resource to retrieve,
     *     or an options array containing an `id` key
     */
    public static function retrieve($id, $opts = null)
    {
        ...
        $instance = new static($id, $opts);
        $instance->refresh();

This is troublesome, because in the first case, $id is "value of an id property that we are deserializing, e.g. it came back on a response", but in the second case, $id means "stuff that the user passed into retrieve."

In both cases, $id can be an array. In constructFrom it can be an array if "id" means "indonesia" and isn't an identifier. Via retrieve it can be an array if the user wanted to send some extra query parameters along with their call to retrieve.

Right now $obj = StripeObject::constructFrom(['inner' => ['id' => ['foo' => 'bar']]]); is crashing because we are always assuming the second case, i.e. the library sees ['foo' => 'bar'] and crashes: "hey wait a minute! You're telling me to send ?foo=bar on a retrieve, but ['foo' => 'bar'] doesn't have an id field and I need to know id to do a retrieve!"

The more disciplined change would be to take this logic completely out of the StripeObject constructor. It should not be shared. That needs to happen in a major, though.

This less disciplined change is just to allow this code path to proceed without id being present. It's safe. This code path just would have crashed before.