Calling a @jit function with a type that cannot be "fingerprinted" uses excessive memory
<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
  visible in the release notes
  (https://numba.readthedocs.io/en/stable/release-notes-overview.html).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This code:

```python
from numba import jit

@jit("none(unicode_type)")
def foo(x):
    pass

while 1:
    foo("x")
```

uses increasingly more and more memory as time goes by (order of megabytes a second). It seems like the issue is that types which end up going through `typeof_pyval` because they cannot be "fingerprinted":
https://github.com/numba/numba/blob/301ba23116864ef66a2caccfab7c7123e7bcbcfc/numba/core/dispatcher.py#L679-L695
will end up being added to this list:
https://github.com/numba/numba/blob/301ba23116864ef66a2caccfab7c7123e7bcbcfc/numba/core/dispatcher.py#L694
on the dispatcher object itself. This list doesn't leak, it is cleared on finalisation, but it grows with every call to the dispatcher with a type that triggers the `typeof_pyval` fallback. I think the list itself exists as a way to keep references alive between computing a type and compilation, but it has the noted side effect if a function is called repeatedly.

I think the the list can be made into a `set`, as types are hashable in general. This may not solve _all_ of the problem as the hash of some types could be `id` based, but it will deal with the most common cases. I have a patch for this locally and it seems to resolve the issue, I'll make a PR hopefully for 0.61.
Calling a @jit function with a type that cannot be "fingerprinted" uses excessive memory
<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I have tried using the latest released version of Numba (most recent is
  visible in the release notes
  (https://numba.readthedocs.io/en/stable/release-notes-overview.html).
- [x] I have included a self contained code sample to reproduce the problem.
  i.e. it's possible to run as 'python bug.py'.

This code:

```python
from numba import jit

@jit("none(unicode_type)")
def foo(x):
    pass

while 1:
    foo("x")
```

uses increasingly more and more memory as time goes by (order of megabytes a second). It seems like the issue is that types which end up going through `typeof_pyval` because they cannot be "fingerprinted":
https://github.com/numba/numba/blob/301ba23116864ef66a2caccfab7c7123e7bcbcfc/numba/core/dispatcher.py#L679-L695
will end up being added to this list:
https://github.com/numba/numba/blob/301ba23116864ef66a2caccfab7c7123e7bcbcfc/numba/core/dispatcher.py#L694
on the dispatcher object itself. This list doesn't leak, it is cleared on finalisation, but it grows with every call to the dispatcher with a type that triggers the `typeof_pyval` fallback. I think the list itself exists as a way to keep references alive between computing a type and compilation, but it has the noted side effect if a function is called repeatedly.

I think the the list can be made into a `set`, as types are hashable in general. This may not solve _all_ of the problem as the hash of some types could be `id` based, but it will deal with the most common cases. I have a patch for this locally and it seems to resolve the issue, I'll make a PR hopefully for 0.61.