Expander refactoring

[fredbi]

Most of this lib complexity lies with the resolver and expander features, but these ones bear almost no specifics about swagger specs.

Factoring out this complex but battle-tested feature could simplify the move to OAI 3.

IMHO, spec expansion should be refactored along the following lines:

• moves the core functionality to a separate package (e.g go-openapi/spec/expander)
• make individual spec objects Resolvable and Expandable
• expose additional tooling like normalization, etc which could be factorized with go-openapi/flatten which now overlaps with this logics quite a bit
• further factorization with analysis to single out common $ref functionality used by spec flattening: complete flattening logics (like name resolution, etc) would remain swagger-specific in analysis, but building blocks such as rebasing refs, replacing refs or schemas could be added to the new common set of tools

e.g. something like equipping spec objects with:

type Resolvable interface {
  ResolveWithRoot(root interface{}, opts ...*ExpandOptions, caches ...ResolutionCache) error
  ResolveWithBase(root interface{}, ref Refable, opts ...*ExpandOptions, caches ...ResolutionCache)  error
}

type Expandable interface {
  ExpandWithRoot(root interface{}, ref Refable, opts ...*ExpandOptions, cache ...ResolutionCache) 
  ExpandWithBase(root interface{}, ref Refable, opts ...*ExpandOptions, cache ...ResolutionCache) 
}

We could provide backward compatibility by leaving methods a the package level.

[fredbi]

Merged two refactoring-only PRs, without changing the interface. This essentially improves readability. I give up on any change of the interface.