add v2 routes

[DimitrisStaratzis]

I used the openapi-v2.yaml to generate the code for the v2 routes. I then restructured the packages to include v1 and v2.

This is the beginning. In following PRs I will also include the v2 routes in our wrapping classes and examples.

[teo-tsirpanis]

This will be a breaking change. Not sure if you want that.

[DimitrisStaratzis]

It will be a breaking change yes, necessary in my opinion to include the new code. Otherwise the packaging will be unclear

[teo-tsirpanis]

I see. I'm leaving it to others to make the decision on the breaking change.

[DimitrisStaratzis]

thanks for the comment!

[ihnorton]

Per discussion, we're going to alias the v1 elements and provide a deprecation pathway.

[DimitrisStaratzis]

Class aliases are not available in Java but I did the following. I created the v1 directory and also left the v1 files in their previous directory. So I pretty match did a copy-paste and we ended up with multiple duplicates. In the files that are in the unwanted directory I added a deprecation warning. These files will be removed in our next release.

[DimitrisStaratzis]

The deprecation warning is:

**
  * @deprecated This class is now moved to io.tiledb.cloud.rest_api.v1.api
  */
 @Deprecated

[ihnorton]

Thanks. Without an aliasing mechanism (java 🙃), this will be an all-or-nothing change: users will need to update all uses at once, because the v1.* types will be semantically distinct even if they are nominally identical. So, if at all possible, we should wait two libTileDB releases before removing the old signatures in order to follow our general deprecation policy.

[DimitrisStaratzis]

sounds good!