2.x and beyond will ship as ESM only. 1.x will continue to have
  backported fixes and non-breaking features.

Instead of traversing objects twice (once to set, once to get), we now keep track of it through the parse loop and key into it gradually as keys are parsed.

When using index nesting, the parse loop visits `[` and computes keys
_only if_ we didn't just pass a `]`.

This is to capture the start of such a key. For example, `foo[bar][baz]`
would result in the only occurrence of this being `foo[`.

Since a syntactically valid indexed key should only have one of these
(at the start), `lastKey` should always be `undefined` at that point. So
we can remove the check.

Changes the stringify logic to build a string up internally rather than
producing an array of traversed key/value pairs.

Should result in a little less memory usage and seems to bump the perf
up a fair amount in some cases.

Re-runs the benchmarks since we changed the parse loop recently.

Sets the publish flow to do the following:

- `1.*` pre-releases have the `v1-next` tag
- `1.*` releases have the `v1` tag
- all other pre-releases have the `next` tag
- all other releases have the `latest` tag

Exports the shared types so we can get hold of `Options` etc.

Adds a new `valueSerializer` option so we can provide a custom value
serializer.

Adds a new syntax type, `js`. With this syntax, arrays use indices and
properties use dot-notation.

For example:

```ts
// foo.bar[0]=baz

({
  foo: {
    bar: [
      'baz'
    ]
  }
})
```

Closes #39

Fixes #42

Essentially we had two bugs 👀

Bug 1: if you have repeat syntax when using bracket-notation, but only
had one key, we would _not_ create it as a string.

For example:

```ts
parse('foo[]=1', opts); // {foo: 1} - wrong!

parse('foo[]=1&foo[]=2', opts); // {foo: [1, 2]} - right!
```

Bug 2: if you have repeat syntax following an index-nested member, we
would not parse it correctly.

For example:

```ts
parse('foo[bar][]=1', opts); // {foo: {bar: 1}} - wrong!

// expected: {foo: {bar: [1]}}
```

These should both now be fixed.

Adds a `shouldSerializeObject` function which determines if a value
should be serialized or should attempt to be nested.

The default implementation checks if a value is a non-date object,
meaning all objects which are not dates will trigger nesting.