Fix behaviour of parameter objects with an 'id' key

[bakerkretzmar]

In #143, which was released somewhere between Ziggy versions 0.6.3 and 0.6.7, a new feature was added to detect when a 'model' object was passed to Ziggy as a route parameter, and use its id property to fill named params if possible.

This allowed us to do the following:

// If our route looks like this...
Route::get('events/{event}', EventController::class)->name('events');

// And we have an object like this, passed down from a controller
// or retrieved via AJAX...
let event = {
    id: 4,
    name: 'Lollapalooza',
};

// ...we can pass it straight in and Ziggy will use the `id` key, even
// though the parameter name is actually `event`
route('events', event);

This is super cool, but there was a bug in its implementation that meant that any route parameter object with an id key passed to Ziggy had that key stripped out, or was entirely re-parsed into an array of ordered, unnamed parameters instead. Notably, this made it impossible (or at least very error-prone) to intentionally pass id as a query parameter.

This PR re-implements that feature a little more carefully—rather than only checking for the presence of an id key, we also now check for the absence of a key matching the route parameter name. I also moved this check to a later point in the process of parsing and replacing the parameters, so it now functions more as a fallback if none of the parameters in question are set explicitly (this also avoids issues when there is actually a named route parameter called id).

Looking again at the route above:

// Because the `event` param is set explicitly, `id` is just added to the query string
// Returns '/events/2?id=9
route('events', { event: 2, id: 9 });

// No `event` parameter passed, automatically uses `id` instead
// Returns '/events/9?location=Times Square'
route('events', { id: 9, location: 'Times Square' });

Fixes #192 and fixes #206.