Remove JITCodeEvent::CODE_REMOVED

Remove JITCodeEvent::CODE_REMOVED

Instead, JitCodeEventHandlers should remember which ranges they have
added, and evict stale entries in the CODE_ADDED or CODE_MOVED event
handlers.

R=mstarzinger@chromium.org
BUG=v8:3918

[wingo, 2015-02-25 11:56:38]

This patch removes the unused JITCodeEvent::CODE_REMOVED event from the API, and
removes the CodeDeletedEvent from the internal log API.

Mostly there is no effect, but as bug 3918 notes, CODE_REMOVED was indeed
getting fired, but only for code objects in LO space, as far as I can tell
anyway.

[Michael Starzinger, 2015-02-25 15:27:16]

mstarzinger@chromium.org changed reviewers:
+ hpayer@chromium.org

[Michael Starzinger, 2015-02-25 15:27:16]

In general I like this cleanup (as it mostly removes code that has been broken
for years). I am just not sure if offloading the work of keeping a map of
previous code-object ranges to invalidate old entries, to the embedder. I would
like to offload it of course, I just would like to get a second opinion. I am
happy to go with this, we should just make it crystal-clear in the v8.h
comments.

Hannes: WDYT?

[Michael Starzinger, 2015-02-25 15:46:23]

mstarzinger@chromium.org changed reviewers:
+ svenpanne@chromium.org

[Michael Starzinger, 2015-02-25 15:46:24]

I talked to Sven about this a bit: He convinced me that the protocol is actually
fine as it is. Because there are cases where a CODE_REMOVED event cannot be
reconstructed from CODE_ADDED and CODE_MOVED. Imagine an external debugger that
has a DisassembleAllJittedCode functionality. This one might potentially look at
released pages without such an event.

The fact that we don't implement all of the protocol (for more than two years!)
correctly is a different story, but probably still doesn't warrant restricting
the protocol.

[wingo, 2015-03-17 15:59:21]

Closed issue, as I don't need the patch any more and it seems CODE_REMOVED could
be useful as per http://code.google.com/p/v8/issues/detail?id=3918.