With the switch to ECMAScript modules, main Reffy functions were exported as
**named** exports but there was no **default** export, meaning Reffy could be
imported through:

```js
import * as reffy from 'reffy';
import { crawlSpecs } from 'reffy';
```

... but there was no way to write:

```js
import reffy from 'reffy';
```

This update makes it possible to do either:

```js
import reffy from 'reffy';
import { crawlSpecs } from 'reffy';
```

Now, the dark side of this feature requires lines some might consider to be
unnatural... In particular, that requires writing similar things 3 times in
`index.js`:

1. First, to import named exports from the different modules
2. Second, to create named exports
3. Third, to create a default Reffy export

There's no way to reduce that. That makes me wonder whether this approach is
good practice. For example, there is a specific syntax in JavaScript for
re-exporting values from other modules:

```js
export { crawlSpecs } from "./src/lib/specs-crawler.js";
```

That is tempting! But that syntax does not import `crawlSpecs` and so cannot
be used to also create a default export with `crawlSpecs` as a property.

Also, while they are written the same way, the values of the `export` and
`export default` syntaxes cannot be combined because they are conceptually
different beasts: the former is a list of names, the latter an object with
properties.

The update does similar magic for the `parse-webidl.js` module. The
post-processor module only exports the processor as a sort of static class and
does not create named exports, because that's how the module is used in
practice.