Update tell.py to support multiple connections

**The issue:**
Currently, if you have your CloudBot connected to multiple networks, the tell command and its PRIVMSG event hooks do only initialize their database connection (aka. create the necessary table if it does not exist) when it has not been initialized. The initialization state is stored in a global boolean db_ready. 
However, if you have multiple connections, the table is created for the first connection the bot receives a message on, but other connections' databases *are not checked*. So, suppose you have two connections, c1 and c2. The bot does the following:
````
Receives message from c1, checks db_ready (is False) -> Creates table, Sets db_ready = True
Receives message from c2, checks db_ready (is True) -> Fails with "table does not exist"!
````

**What this does:**
This PR resolves above issue by storing whether the database is ready *per connection*. It does that by changing db_ready to a list and adding every initialized (i.e. table was created) connection's name to it. 
Instead of checking for `not db_ready`, it checks for `db_ready.count(conn_name) < 1`. 
So our previous example would look like this:
````
Receives message from c1, checks db_ready contains c1 (False) -> Creates table, Adds c1
Receives message from c2, checks db_ready contains c2 (False) -> Creates table, Adds c2
````
This also changes a (unused) parameter name from `paraml` to `inp` (shorthand for input), because I think that fits better what it does.

It also adds a missing apostrophe to a message (Changes from `cant` to `can't`)

**How to reproduce:**
Clone a new CloudBot. Add two networks to your config file. Write a message on the first connection and then on the other connection. The second time, a stack trace is printed with a `table does not exist` error. (2 tell commands should also work for reproducing)

This exact patch is currently being run on my bot and no issues have occurred.

*If the text of this PR seems familiar to you, I have copied the one from #209 (and adapted it for this change) because the issue and solution are nearly exactly the same.*

Thank you!