Separate API and impl, fix all leaked internal references, put API in v1 package.

[jakewins]

• This moves the entire API into a versioned package, v1, which is
  intended to match the major version of the driver. Using this approach
  we will be able to keep non-compatible versions of the API entirely
  segregated. Whenever we release a breaking API, we release it as
  a wholly new API, technically. This also means we can run a new API
  side-by-side with an old API, meaning large applications can do
  incremental upgrades - each module using Neo4j can upgrade at its own
  pace.
• Also remove all circular references from the API to the implementation,
  the API no longer leaks any implementation aspects. This will mean we
  can provide this same API with other implementations without issue,
  which is a nice step forward from the old Core API.
• Permanently enforce this second change using Macker, failing the build
  if we ever introduce a circular dependency from the API to the impl.

[jakewins]

@boggle realized when I opened this that this is very similar to #84

This takes a slightly different approach:

org.neo4j.driver.v1 // API
org.neo4j.driver.internal // standard implementation

I actually don't really care which option we do - but if we choose to merge the other PR, I'd love to move the work in this PR pertaining to fixing the parts of the API that leak internal classes over (see the 'Macker' plugin added to the pom here)

Do you have a preference of v1 containing both impl and API or v1 containing only API?

[jakewins]

Actually, I think I like the other approach better, I'm gonna close this and move the macker changes in after we merge that other PR

[boggle]

In Cypher, we've used internal.v1 with success. Perhaps that addresses all concerns?

[jakewins]

@boggle oh, I think I like that. More importantly - as long as we make sure to not have any imports API -> impl, we are free to make whatever changes we like later