Hello folks, here I tried to add support for `schemaName` into `INSERT`,
`UPDATE`, `DELETE` and some sub variants of those. I feel 90% confused
about most of the stuff I see in the repo so far, but I wanted to start
somewhere, so I can gradually get a better understanding of what's going
on.

Here I implemented a `Table.resolve` function that should make a fully
qualified table name + schema if present + apply mapping from config,
maybe it can also be used further for #53
I also thought it's a good idea whenever `Table.Base` becomes `String`
to be used as a fully qualified name to not do any further processing
and mapping of this string
 Fixes #54

---------

Co-authored-by: nikitaglushchenko <[email protected]>

This PR here is somewhat a beginning of a conversation about how do we
want to make proper sql identifiers when it comes to schemas, tables and
columns, particularly for my use case I want this in order to use sql
reserved words for table names. I'll try to split this into 2 logical
parts:

**How do we know how to escape depending on db variant?**
A SQL 1999 rfc says that double quotes should be used in order to escape
an identifier, nevertheless:
- in mysql it is backticks
- in h2 when you escape you suddenly loose the ability to refer to a
table ignoring it's definition case: defining a table `T`, `SELECT *
from t` will work, `SELECT * from "t"` will not

Therefore it felt logical to make an escaping mechanism based on
`Dialect`. I didn't want to propagate `DialectConfig` together with
`Context` down the call chain, it seemed to me kinda redundant, so I
made `DialectConfig` part of `Context`. That's how we can access
escaping mechanism in various places as long as you have `Context`

**How do we decide which table to escape?**
With this PR I want to stick with tables, otherwise it can become too
big. I see three options:
1. escape all tables
2. escape based on list of reserved words per database variant
3. let user decide to escape

First options we already discarded as one that will change too much
tests. As for a second option - I looked into lists of reserved words,
and they are very different based on database, also it will not be fun
to maintain them, that's why most of the libs resolve to escape all
tables. Third option is most simple for now, since it will allow users
to opt-in when they want/bump into this issue, also it will allow us to
test mechanism first without changing all 1k+ tests, and perhaps we can
start with option 3 and then eventually move to option 1. Therefore in
this draft PR I made a flag in `Table` to opt in for escaping table
name.

_Optional_:
At the moment `DialectConfig` is kinda part of the `Dialect`, and I
don't feel entirely good about including whole `Dialect` in `Context`. I
kinda want to move `DialectConfig` into case class and make a separate
implicit for it as a part of `Dialect` so that when we need to construct
`Context` only `DialectConfig` case class will be picked up

It is a draft PR yet, so obviously I haven't written tests for all
cases, only for a simple `FROM` expression. This will follow when we
come to consensus about the implementation.
What do you guys think?
fixes #53