```
import mimetypes

print(mimetypes.guess_type('foo.manifest'))
mimetypes.add_type('text/plain', 'manifest')
print(mimetypes.guess_type('foo.manifest'))
```

results in:

```
('application/x-ms-manifest', None)
('application/x-ms-manifest', None)
```

I (mistakenly) expected the latter print to give me "('text/plain', None)".  It doesn't because I should have prepended a . to the second add_type argument.

I think add_type should error out when given an extension without a dot-prefix, because it's extremely unlikely that code that does so is behaving as intended with the current implementation.

(At the very least, documentation should be updated to make this expectation clearer.)

Ideally, use .startswith('.') Instead if find, but this is a clear UI fix. First pull request fixes doc, second fixes code. OK to apply both.

I think we should deprecate calling `add_type` with an empty `ext`, as I don't think it's a feature, more a side effect of the current implementation.

But as some may use it like a feature, I asked the current PR to emit a warning, to not break the current implementations.

To be able to simplify in the future, why not deprecating empty `ext` so we can remove it in a few versions?

I just found a case where the empty mime type is actually usefull, it's in Lib/http/server.py:

    extensions_map = mimetypes.types_map.copy()
    extensions_map.update({
        '': 'application/octet-stream', # Default
        '.py': 'text/plain',
        '.c': 'text/plain',
        '.h': 'text/plain',
        })

It does *not* uses add_type, but demos the fact that the empty type may be usefull from time to time, maybe don't warn and don't deprecate it at all.