More accurate support for lock prefixed instructions

Start by locating the HLIL decompiler handling for lock-prefixed instructions, using the assembly and HLIL examples in the issue as the behavioral reference. The change should preserve the interlocked meaning of increment, decrement, compare, and other lock-prefixed operations rather than presenting them as ordinary arithmetic.

First of all, I want to congratulate anyone who works on BN. I'm evaluating replacing my daily reverse engineering tool (which, I guess anyone who reads this already knows him.) with BN. More than that, I feel like I want to work at Vector35. That is what I really feel about BN. So thank you all for putting this effort into this beautiful project. There are a lot of things already in BN that I want to saw in other tools. But of course there are some other things I want to saw in BN, too! So, here is another one for you... I mean, for us...

Currently, BN's decompiler turns this assembly

004010a0  int32_t list_push(struct list_T* list, struct person_T* person)

004010a3  8b4508         mov     eax, dword [ebp+0x8 {list}]
004010a6  83c004          add     eax, 0x4
004010a9  f0ff00             lock inc dword [eax]

into this in HLIL view:

004010a0  int32_t list_push(struct list_T* list, struct person_T* person)
004010a6      list->size = list->size + 1

I think it would be more accurate if decompiler make us know that this is an interlocked increment. Maybe something like this?

InterlockedIncrement(&list->size);

There are other variations(decrement, compare etc..) too for sure. Support for all of them in a release would be very pleasant.