Re-organize project

[dave-tucker]

• move all ovsdb notation to ovsdb. this provides a clean separation between
  a) marshalling/unmarshalling of ovsdb datatypes and mapping to go types
  b) client code (e.g cache, orm, api etc...)
• examples/stress and examples/print_schema to cmd as they are useful commands (more than examples)
• fixes the error messages to be lowercase (which gopls insists on)
• adds a .golangci.yml to attempt to replicate ^ but doesn't quite yet - i need to investigate this more thoroughly

[coveralls]

Pull Request Test Coverage Report for Build 831148708

• 90 of 113 (79.65%) changed or added relevant lines in 12 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-3.9%) to 74.613%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
client/api.go	11	12	91.67%
ovsdb/schema.go	0	1	0.0%
client/model.go	5	7	71.43%
client/cache.go	4	7	57.14%
client/client.go	24	27	88.89%
ovsdb/bindings.go	23	26	88.46%
client/orm.go	13	18	72.22%
client/orm_info.go	6	11	54.55%

Totals
Change from base Build 817648290:	-3.9%
Covered Lines:	1349
Relevant Lines:	1808

---

💛 - Coveralls

[amorenoz]

I haven't taken a deep look but sharing a couple of initial thoughts:

• Should we put subpackates into "pkg" directory to comply with the 'standard' golang project layout?
• Should we put the client code into another subpackage so that the user has a more clear idea of what the packages do?
  E.g:

import "github.com/go-ovn/libovsdb/pkg/client"
import "github.com/go-ovn/libovsdb/pkg/ovsdb"

vs

import "github.com/go-ovn/libovsdb"
import "github.com/go-ovn/libovsdb/pkg/ovsdb"

[dave-tucker]

@amorenoz based on our chat yesterday I've updated this.
We have a dedicated client package as well as an ovsdb package.
These don't live in the pkg directory, as that is typically used for useful packages that could be used by others, independent from the primary use of the library.

[amorenoz]

@dave-tucker LGTM, only comment is, if we ever want to have another module (e.g: server) use the ORM layer, it would have to be moved to a common place. It's all private so it would not affect the client API I believe

[dave-tucker]

@amorenoz good point. I'll merge this as-is, and we can look at splitting out the orm layer in to it's own package later.