Makes Core and DB assertions coexist with only one import

[jmaniquet]

Proposal for : #329

The suggested implementation works nicely in my eyes : I am able to use both core and db assertions while using only one single org.assertj.core.api.Assertions.assertThat static import.

Now I did encounter a problem : class Changes_Constructor_Test stopped compiling with that implementation.
The reason is statements like this :

1. assertThat(changes.getRequestAtStartPoint()).isNull();
2. assertThat(changes.getTablesAtStartPointList()).hasSize(5);

The first assertThat used to return an ObjectAssert - which provides isNull assertion
The second used to return a ListAssert - which provides hasSize assertion

After the fix they respectively provide ChangesAssert and TableAssert, since inputs are now treated as AssertProvider instances.

I identified two possible workarounds :

1. Keep assertThat static import with something like this : assertThat((Object) changes.getRequestAtStartPoint()).isNull();
2. Remove it and declare custom assertThat methods with signatures that suit me

I went with second one; but neither maybe acceptable; let me know.

If we go forward with a fix (whatever it may be), I see also this :

• Clear bonus : it seems to work with BDDAssertions.then which has the same characteristics (I did not notice at first since i do not use it) - AssertJ Core provides its then variants and one has an AssertProvider overload
• Possible bonus : assertThat and then methods from AssertJ DB seems to become obsolete, and maybe can be deprected; even removed in the future. I could be wrong though.

I also added a commit that changes the pom version to a new Snapshot.
I am not sure if I was supposed to do it or not; but I can remove this commit if need be.

Let me know what you think

[scordio]

• Possible bonus : assertThat and then methods from AssertJ DB seems to become obsolete, and maybe can be deprected; even removed in the future. I could be wrong though.

I had the same line of thinking – let's see if it's feasible.