knex v1+ changed the return values when `.returning()` clause is used (affecting postgres), before it returned array of primitive values if only 1 column was selected to be returned (e.g. `[1]` for `.returning('id')`) but now it always returns objects (e.g. `[{ id: 1 }]` for `.returning('id')`).

Slightly reorganized `InsertOperation`, instead of calling `createModels` in `doExecute()` (right after `onRawResult` hook) and having "empty" model instances created there, possibly with undefined / declared default properties which would later overwrite input models in `InsertOperation.onAfter1`, offload the handling to `InsertOperation.onAfter1`, which now uses also `setDatabaseJson`, same as `createModels` function, to be consistent.

Additionally, adjusted `$parseDatabaseJson` in `GraphInsert` integration tests, to only parse boolean values when they are present in `json`.

related change in knex v1.0: knex/knex#4471

* bump typescript, knex and @types/node to get rid of typing errors in test:typings

* adjustments for knex v1+

knex v1+ changed the return values when `.returning()` clause is used (affecting postgres), before it returned array of primitive values if only 1 column was selected to be returned (e.g. `[1]` for `.returning('id')`) but now it always returns objects (e.g. `[{ id: 1 }]` for `.returning('id')`).

Slightly reorganized `InsertOperation`, instead of calling `createModels` in `doExecute()` (right after `onRawResult` hook) and having "empty" model instances created there, possibly with undefined / declared default properties which would later overwrite input models in `InsertOperation.onAfter1`, offload the handling to `InsertOperation.onAfter1`, which now uses also `setDatabaseJson`, same as `createModels` function, to be consistent.

Additionally, adjusted `$parseDatabaseJson` in `GraphInsert` integration tests, to only parse boolean values when they are present in `json`.

related change in knex v1.0: knex/knex#4471

* introduced new (or missing) knex querybuilder's methods

to make shapes of both querybuilders as close to each other as possible.
Most of the methods were introduced in knex v1.
- `fromRaw`
- `whereLike`
- `andWhereLike`
- `orWhereLike`
- `whereILike`
- `andWhereILike`
- `orWhereILike`
- `withMaterialized`
- `withNotMaterialized`
- `jsonExtract`
- `jsonSet`
- `jsonInsert`
- `jsonRemove`
- `whereJsonObject`
- `orWhereJsonObject`
- `andWhereJsonObject`
- `whereNotJsonObject`
- `orWhereNotJsonObject`
- `andWhereNotJsonObject`
- `whereJsonPath`
- `orWhereJsonPath`
- `andWhereJsonPath`
and one new `JoinBuilder` method - `andOnJsonPathEquals` (referencing knex's `JoinClause` method of the same name)

`whereJson(Not)SupersetOf` / `whereJson(Not)SubsetOf` are now supported by knex >= 1.0, but for now
objection handles them differently and only for postgres.
Changing them to utilize knex methods directly may require a major version bump and upgrade guide.

Added a test for checking JoinBuilder methods to be inline with knex's JoinClause.

Fixed incorrect checking QueryBuilder methods if they are inline with knex's QueryBuilder.

Added typings for new methods.

Bumped knex `peerDependency` from `>=0.95.13` to `>=1.0.1` because of new methods.

This is latest Knex version v1.x.x

https://github.com/knex/knex/blob/176151d8048b2a7feeb89a3d649a5580786d4f4e/CHANGELOG.md#107---13-april-2022
The only thing from Migration guide (linked above)
that looks like it can affect us is:
> `RETURNING` operations now always return an object with column names;

But looking at PR which added this feature -
knex/knex#4471
and PR that updated documentation -
knex/documentation#378
we can see that we're not affected, since
we always use `returning` as `returning('*')`

Changes to type definitions have one important change,
since `QueryCallback` was defined like this in `v0.95.15`
https://github.com/knex/knex/blob/0.95/types/index.d.ts#L1782

```ts
type QueryCallback<TRecord = any, TResult = unknown[]> = (
  ...
) => void;
```

which has changed to this in `v1.0.7`
https://github.com/knex/knex/blob/1.0.7/types/index.d.ts#L1842

```ts
type QueryCallback<TRecord extends {} = any, TResult = unknown[]> = (
  ...
) => void;
```

We can see that `extends {}` was added to `TRecord`,
so we need to make the same adjustment, otherwise
we get an error "Type `InstanceData` does not satisfy the constraint `{}`"

After this change, we can also reduce type assertions
in query building

This is latest Knex version v1.x.x

https://github.com/knex/knex/blob/176151d8048b2a7feeb89a3d649a5580786d4f4e/CHANGELOG.md#107---13-april-2022
The only thing from Migration guide (linked above)
that looks like it can affect us is:
> `RETURNING` operations now always return an object with column names;

But looking at PR which added this feature -
knex/knex#4471
and PR that updated documentation -
knex/documentation#378
we can see that we're not affected, since
we always use `returning` as `returning('*')`

Changes to type definitions have one important change,
since `QueryCallback` was defined like this in `v0.95.15`
https://github.com/knex/knex/blob/0.95/types/index.d.ts#L1782

```ts
type QueryCallback<TRecord = any, TResult = unknown[]> = (
  ...
) => void;
```

which has changed to this in `v1.0.7`
https://github.com/knex/knex/blob/1.0.7/types/index.d.ts#L1842

```ts
type QueryCallback<TRecord extends {} = any, TResult = unknown[]> = (
  ...
) => void;
```

We can see that `extends {}` was added to `TRecord`,
so we need to make the same adjustment, otherwise
we get an error "Type `InstanceData` does not satisfy the constraint `{}`"

After this change, we can also reduce type assertions
in query building