fix: add ts:node16 support

feat: add support for escaped composite keys on expressions

feat: restore CJS compatibility

feat: expression attribute values by types (#49)

* make values of different types to be encoded separately.

* make values of different types to be encoded separately.

feat: export types IDynoexpr*

feat: don't use absolute import on exported type file

feat: drop aws-sdk dep, accept it as a parameter when working with Sets

fix: update deps, security fixes

feat: bump version

feat: avoid instantiating DocumentClient

This refactor avoids instantiating a DynamoDB.DocumentClient object
(which in turn would instantiate an underlying DynamoDB service client)
by accessing the `createSet` method from the prototype directly.

The interface for `createSet` is:

```typescript
    createSet(list: number[]|string[]|DocumentClient.binaryType[], options?: DocumentClient.CreateSetOptions): DocumentClient.DynamoDbSet;
```

And the implementation is:

```typescript
  createSet: function(list, options) {
    options = options || {};
    return new DynamoDBSet(list, options);
  }
```

As we can see, there is no reliance on the `this` instance, so calling
the method from the prototype with an undefined `this` value should work
fine. It would have perhaps been preferred to utilize the `DynamoDBSet`
class directly, but that is marked with `@private` annotations within
the AWS SDK while the `createSet` method on DocumentClient is part of
the public API.

Aside from the removal of client instantiation, this change also scopes
imports to just the DynamoDB specific resources. This has been measured
to improve performance by several milliseconds in Lambda runtimes.

This somewhat relates to issue #29, but it doesn't really address it.