add "Not Null" for create statement, fix postgres varchar size, add more struct tags/features

[pbnjay]

A few commits for consideration:

1. postgresql varchar doesn't need a size - if there's not one set then don't set it to 255.
2. add a simple SetNotNull similar to SetUnique
3. the big one - add json-package-style comma-tags (like pull Field tags now allow you to declare a primary key or autoincrement field #26), and a couple other handy struct tags. I'm sure the names themselves can be changed to suit your preference.

I spelled out as much as I could in the commit log message:

Adds some features to the db: tag similar to the json package.
Use a comma-list of special words as follows:
 ** first item is always column name **
  "ai" = autoincrement
  "pk" = primary key
  "un" = unique
  "nn" = not null

Add a dbdefault: tag to set a default value
Add a dbrefs: tag to set a (single-column) foreign key constraint
Add a dbtype: tag to set a database-layer data type without having to
    deal with updating the Dialect. You'll probably want something the DB
  can convert from a string type transparently.

NB: These 3 tags are directly placed into the create table statments, so
any necessary quoting or escaping must be handled properly. These are
shortcuts, don't use them for complex constraints!

A contrived example of usage:

type Building struct {
    Id        int64  `db:"building_id,pk,ai"`
    Name      string `db:",nn" dbdefault:"NoName Building"`
    Address   string `db:",nn,un"`
    GatewayIP string `db:"ip_address" dbtype:"inet"`
}

type Room struct {
    Id         int64  `db:"room_id,pk,ai"`
    BuildingId int64  `db:"building_id,nn" dbrefs:"buildings (building_id)"`
    Name       string
}

[coopernurse]

Thanks for the contributions.

Re: b7d1729: I think it's an interesting idea, but I want to think about it more. It changes existing behavior, which may surprise some users, and it impacts portability. Also, since Dialect is an interface, it's pretty easy to just make your own with this (or any other) behavior. If you feel strongly about it, please open a separate issue for this so we can get opinions from other folks watching this repo.

Re d9421a6: Looks good. I'm going to merge this into the develop branch, which is where I'm starting to stage changes in batch before folding into master.

Re 76d12f3: Good ideas here, but there's a lot of activity in this general area (2-3 other PRs). So I'm going to hold off on this too. I'm going to create a master ticket for the "grand tag enhancement" feature so we can hash out the best way to deal with this and get feedback from everyone.

cheers

[coopernurse]

I'm going to close this out, but I opened #79 to track the d9421a6 commit

thanks