* phpunit: use dedicate `Tests` namespace for tests
* tests: replace phpunit with orchestra/testbench
* phpunit: ignore result cache file
* phpunit: adapt test for newer version
* tests: add base testcase class with a helper to run/assert commands
* tests: add test for ide-helper:eloquent
* travis: add global default variables
* travis: disable xdebug, speeds up running tests
* travis: convert php versions to build matrix for environment vars
* travis: only run phpcs/phpunit when the env vars signal it
However phpcs only runs with one test combination from the matrix,
not necessary to execute it every time.
Laravel 5.8 introduced a feature to support a custom date class via
`Date::use()`, see https://github.com/laravel/framework/pull/25320
When e.g. using `Date::use(CarbonImmutable)` in a project, it means
all date casts are not returning `\Illuminate\Support\Carbon` anymore
but `\Carbon\CarbonImmutable`, which means all the generated type hints
for dates are now wrong.
This change tries to be still backwards compatible with Laravel < 5.8
which do not have the Date facade.
A cast in Laravel should only affect the type, but not the database intrinsics whether a column accepts `null` or not.
As an example, consider this table (Postgres syntax):
```sql
CREATE TABLE foo (
some_column jsonb
);
```
This will be generated as: `@property string|null $some_column`
When providing a the following casts on the model:
```php
protected $casts = [
'some_column' => 'array',
];
```
then the generated property changes to: `@property array $some_column`
However the DB still accepts `null`, but this can't be expressed via the casts.
This change will make the null "sticky" and generate: `@property array|null $some_column`
Markus Podar