3.x: custom piece admin filter of type select breaks admin UI

## To Reproduce

1. Create a piece module having field `category` of type `select` and add filter:
```js
module.exports = {
// ...
filters: {
add: {
category: {
label: 'Category',
type: 'select',
choices: [
{
label: 'Cat 1',
value: 'cat1'
},
{
label: 'Cat 2',
value: 'cat2'
}
]
}
}
}
// ...
};
```
2. Add new record
3. After submission, when you come back to the list, it's empty
4. The API route called is: `api/v1/tags?apos-mode=draft&archived=false&category&page=1` (note the `category` query string)
5. The list will be empty until you use the filter and choose a value. You are not able to see all results.

### Fix attempt 1
1. change the filter to have default value `null`
```js
module.exports = {
// ...
filters: {
add: {
category: {
label: 'Category',
type: 'select',
choices: [
{
label: 'Cat 1',
value: 'cat1'
},
{
label: 'Cat 2',
value: 'cat2'
}
],
def: null
}
}
}
};
```
2. same result as before with same API route called

### Fix attempt 2 (different behavior)
1. add manually a null value choice, don't use default value
```js
module.exports = {
// ...
filters: {
add: {
category: {
label: 'Category',
type: 'select',
choices: [
{
label: 'Any',
value: null
},
{
label: 'Cat 1',
value: 'cat1'
},
{
label: 'Cat 2',
value: 'cat2'
}
]
}
}
}
};
```
2. the list is now visible
3. filter by any non null `category` value (works as expected)
4. try to edit a record - record not found notification
4. change to `Any` - empty list again

In all of the cases above (list) the corresponding query log is:
```js
{
'$and': [
{ archived: { '$ne': true } },
{ type: 'tags' },
{ '$or': [ { aposLocale: 'en:draft' }, { aposLocale: null } ] },
{ category: { '$in': [ '' ] } }
]
}
```

## Expected behavior
To work as expected. However they are different layers of this bug. It's not entirely clear to me if the UI don't have to send null values in this case, or the backend should properly filter them out. I can see a need of backend to build somehow in some cases a `field=null` db criteria...

Additionally, I think the edit (getOne) API request made from admin UI should ignore the filters explicitly.

## Describe the bug
The filter is breaking the API requests for list and edit.
Details in the reproduce section

## Details

**Version of Node.js:**
v12.21.0

**Operating System:**
Ubuntu 20.04.2 LTS

Reproduce the custom piece admin filter with a select field and inspect the api/v1/tags request and the logged query containing category: { '$in': [ '' ] }. Compare list behavior for an unset value, a non-null choice, and an Any/null choice, then verify that editing a filtered record succeeds and that getOne does not apply list filters. Done means the list shows all records without a selected filter and filtering still works.

Written by the indexing model from the issue text.