Removal of increment and decrement functionality

[boesing]

Q	A
BC Break	yes

Description

As per #117, the increment and decrement functionality (at least decrement) leads to issues with several backends. This commit removes that functionality at all as it should be either part of specific adapters instead (via dedicated interface) or as part of project specific code. This cache component can not guarantee increment/decrement for all adapters out there (especially for adapters which do not support this feature natively to prevent race conditions).

[boesing]

BC compatibility check is expected, this PR introduces a BC break on purpose.

---

@Ocramius does it make sense to add a way that the BC check is passing once BC Break label is added to a PR?
I mean, I guess its fine that the check is red here as it actually does introduce a BC break but it still feels kinda "wrong" as it is expected. So this is just an idea I'd like to bounce.

[boesing]

• Remove event listeners listening to incrementItem, incrementItems, decrementItem and decrementItems events

[Ocramius]

BC compatibility check is expected, this PR introduces a BC break on purpose.

@Ocramius does it make sense to add a way that the BC check is passing once BC Break label is added to a PR? I mean, I guess its fine that the check is red here as it actually does introduce a BC break but it still feels kinda "wrong" as it is expected. So this is just an idea I'd like to bounce.

IMO NO: can just decide to merge with red, which is a clear/visible flag