Amqp remove deprecations

[makasim]

I am targeting this branch, because there is a BC-break.

Follow up #276

Changelog

### Removed
- The pull request removes previously deprecated stuff from the PR [#276](https://github.com/sonata-project/SonataNotificationBundle/pull/276). Now AMQP implementation relies on amqp interop and no longer coupled to php-amqplib. 

Subject

The pull request remove previously deprecated stuff from the PR: #276

[makasim]

@greg0ire Should I make classes final? properties private? while I am on it.

[greg0ire]

Hey there!

It looks like you did not fill the pull request template properly. Maybe you
were confused, so let me walk you through this step by step.

Explaining why you target this branch

I am targeting this branch, because {reason}.

Here, you are supposed to replace {reason} with something like:

• "there is a BC-break" if you picked the master branch
• "there is no BC-break" if you picked the stable branch

Searching and finding related issues

Closes #{put_issue_number_here}

Please have a look at the list of issues and pull requests, and look for issues
that will be fixed, and pull requests that will become irrelevant should we
merge your PR. Each issue / pull request has a number shown right next to the
title. Kindly replace {put_issue_number_here} with whatever issue or PR is
relevant. Of course, you may specify several numbers.
On merge, these issues and PRs will automatically get
closed.
If there is no issue or pull request that fits there, just remove the sentence
entirely.

Filling the changelog

That one is really important to get right, because it will be used to craft a
release changelog such as this
one.
The first thing you need to know about this is that if your pull request is
pedantic, meaning it does not fix a bug for the user, or adds a new feature, it
is not needed. This is typically the case for PRs that fix the build or add
some documentation.

3 important things:

1. Make sure to fill the changelog section with something directed at the end
   user, that answers the question "What benefit do I get from upgrading?".
2. Make sure to remove empty sections.
3. Make sure to keep the markdown markup.

Filling the TODO list

If you think your PR is ready, just remove it. If you have still some things
left to do, customize it.

Filling the Subject

Last but not least, describe your PR as well as you can. Bear in mind that some
reviewers do not even use the library they are maintaining, so try to be
crystal clear.

[greg0ire]

@greg0ire Should I make classes final? properties private? while I am on it.

Sure! Just make sure to mention it the upgrade note, a bit like this: https://github.com/sonata-project/GoogleAuthenticator/blob/2.x/UPGRADE-2.0.md

[greg0ire]

Wow that's a lot less code, nice!

[greg0ire]

Well technically, you can. It will just have no effect.

[makasim]

@greg0ire is there anything else that prevents us from merging it?

[greg0ire]

Please address this: #283 (comment)

@greg0ire is there anything else that prevents us from merging it?

The lack of reviews. I try not to merge if I'm the only reviewer.
@sonata-project/contributors please review

[makasim]

@greg0ire is there anything else that prevents us from merging it?
done

[greg0ire]

Please address that part: "Explaining why you target this branch"

[makasim]

Please address that part: "Explaining why you target this branch"

done

[greg0ire]

Thanks @makasim !