Move the multimap assertions out of api package

[mattbertolini]

Since I've started up work on this again, I've realized that there really isn't a need for the .api. package in this library. I originally was mirroring the eclipse collections package structure but they have an explicit api and impl library split. There is no such need for this split in the assertions so I am going to shorten the package structure.

It will now look like this:

org.assertj.eclipse.collections --> Root package with entry point assertions type and abstract core types
org.assertj.eclipse.collections.multimap --> for Multimap assertions
org.assertj.eclipse.collections.bag
org.assertj.eclipse.collections.set
org.assertj.eclipse.collections.list
org.assertj.eclipse.collections.map
org.assertj.eclipse.collections.primitive --> for primitive collection assertions
org.assertj.eclipse.collections.error --> error support types

There may be some internal subpackages but too early to tell right now.

[scordio]

If you're considering simplifying the package structure, you might even consider having all assertion classes at the same level as the entry point classes.

Just FYI, assertj-guava also follows a simplified package structure:

org.assertj.guava
              |- .api
              |- .error
              |- .util

In this case, the api package is more of an AssertJ convention than something inspired by Guava.

assertj-vavr also follows same convention.

Of course, feel free to go with the setup you feel more comfortable with!

[mattbertolini]

I like that structure. I rather it be consistent with other conventions in the org. Better for understanding and contributions. I'll make that change to the PR sometime today!