This PR looks to solve some anomalies that have been discovered with
model extending.

## Problem A

When replacing a Lunar model, there are instances where the model
provided by Lunar is still used for example, if you replace the model
like so

```php
\Lunar\Facades\ModelManifest::replace(
    \Lunar\Models\Contracts\Order::class,
    \App\Models\Order::class
);
```

Later in the Lunar core, we are still referencing
`Lunar\Models\Order::first()` or via relationships
`$orderLine->order()`. We attempted to resolve these queries to their
concrete replacements by overriding the `newModelQuery` method, however
there were issues with castable attributes which caused them to be cast
multiple times, resulting in errors.

### Solution

This has been rewritten so Lunar doesn't try to `fill` the extended
instance of the model from the Lunar base class anymore and instead just
populates the attributes as they are. Since this should just be a simple
class swap it should no longer result in duplicate calls to attribute
casters.

There are some additional checks to see if we are actually working with
a model that hasn't been extended to ensure we are not getting into a
situation where we try and rehydrate with the same class.

### Affected issues

This change should resolve #1942 #1930 

## Problem B

If your own custom model was named something other than it's
counterpart, for example:

```php
\Lunar\Facades\ModelManifest::replace(
    \Lunar\Models\Contracts\Order::class,
    \App\Models\MyCustomOrder::class
);
```

This would result in the table name and subsequent foreign key naming to
be incorrect i.e. `my_custom_order` and `my_custom_order_id`. This would
mean developers would need to add their own methods to override this in
order for the naming to resolve properly, which is a bit of a
maintenance burden and easily missed when encountering errors.


### Solution

The `HasModelExtending` trait now provides its own `getTable` and
`getForeignKey` methods which will check which class within Lunar we are
extending and return the appropriate table name and foreign key.

## How this slipped through testing

Looks like there was an oversight and although there were tests for
extending models, the tests themselves didn't use any extending when
performing more complex tasks, like creating orders from carts.

This PR has now added some model extending to tests which were affected
by the issues referenced above to hopefully keep this in check and make
for a more "real world" test environment.

---------

Co-authored-by: alecritson <[email protected]>