add dr_appcode_mark() API for marking heap, client, or private libs

_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on July 24, 2012 11:33:31_

xref my comment in r478 which allowed DR mem as app code:
/\* clients are allowed to use DR-allocated memory as app code:
\* we give up some robustness by allowing any DR-allocated memory.
\* XXX: should we instead have some dr_appcode_alloc() or
\* dr_appcode_mark() API?
*/

xref issue #487 which allowed client libs as app code

now we're hitting issues where we may want private (non-client) libs as app code.

e.g., the drwrap library: http://codereview.appspot.com/6416052/diff/1/ext/drwrap/drwrap.c#newcode924 this is a debugging feature to detect bugs in the isolation engine as
well as mistakes by clients. to maintain that as well as give flexibility
to clients, this issue covers the original XXX of adding an API rather than having blanket rules.

however, for the drwrap situation, it makes sense to extend issue #487 to include Extensions, which are really client libs. it's much more important to detect the app running the private copy of libc instead of the app's libc than to detect the app running an Extension.

_Original issue: http://code.google.com/p/dynamorio/issues/detail?id=852_