Releasing thread and URL reference when the workerized function is not needed

Great library, very useful stuff and absolutely love the size. :)

I've only recently started learning about `Web Workers` and took a look at the source code. So apologies in advance if I am wrong ;). 2 things caught my eyes:

```js
const workerURL = URL.createObjectURL(new Blob([script]));
// Create an "inline" worker (1:1 at definition time)
const worker = new Worker(workerURL);
```

So if we do something like the following snippet (taken from the README), it seems that each new function instantiated via `greenlet(...)` will reserve a new thread and a new URL reference.

```js
import greenlet from 'greenlet'

let getName = greenlet( async username => {
let url = `https://api.github.com/users/${username}`
let res = await fetch(url)
let profile = await res.json()
return profile.name
})

console.log(await getName('developit'))
```

So, if there is a case wherein I don't need to use `getName` after a certain point in my code, those resources are still trapped. They may be very less in size to be of a practical concern, but I am not sure about it and would love if anyone can comment on that.

However, if the output function `getName` comes with a `dispose` method which releases those references, it could be useful. WDYT? Something like:

```js
getName.dispose() // Release references
```

Internally, it could call:

```js
window.URL.revokeObjectURL(workerURL);
worker.terminate();
```

Post `dispose`, `getName` can itself become `undefined` so it's not callable. Or can `throw` a more informative error: `The function is disposed/discarded due to .dispose() call.`.

Is there a downside to this approach if the contributors already considered any similar approach?

Commencez par le code source autour de la création de workerURL et de l’appel à new Worker, puis comparez-le avec l’exemple du README utilisant greenlet. Déterminez si la fonction renvoyée doit exposer un mécanisme de libération et quel nettoyage ou comportement après la libération est requis. C’est terminé lorsque la décision concernant le cycle de vie de la ressource est implémentée de manière cohérente avec l’API proposée.

Rédigé par le modèle d'indexation à partir du texte de l'issue.