condformats_serialization_generate.py: support for aarch64

`libClang` seems to act differently on AArch64 causing `condformats_serialization_generate.py` always to select 0 classes. It happens that `is_definition()` on AST node mostly returns false.

Even on such small examples:
```
$ cat my.h
struct timespec
{
  int tv_sec;
  int tv_nsec;
};
```
On Fedora 20 on x86_64 
```
displayname: timespec, kind: CursorKind.STRUCT_DECL, is_definition: True,  location:<SourceLocation file 'my.h', line 1, column 8>
>> get_definition().location: <SourceLocation file 'my.h', line 1, column 8>
```

On Fedora 19 on aarch64
```
displayname: timespec, kind: CursorKind.STRUCT_DECL, is_definition: False,  location:<SourceLocation file 'my.h', line 1, column 8>
>> get_definition().location: <SourceLocation file 'my.h', line 1, column 8>
```
Change checks if node (declaration record) and it's definition location (file, line and column) match. If match is found, it's a definition.

Details from `libClang` side:
```
Breakpoint 1, clang_isCursorDefinition (C=...)
   at /home/david.abdurachmanov/new-arch/test/BUILD/fc19_aarch64_gcc490/external/llvm/3.4-cms2/llvm-3.4-6800b6d2afc/tools/clang/tools/libclang/CIndex.cpp:4709
4709      if (!clang_isDeclaration(C.kind))
(gdb) p C
$1 = {kind = CXCursor_ClassDecl, xdata = 0, data = {0x7fb39e60e0, 0x0, 0x7fb000cfb0}}
(gdb) p clang_getCString(clang_getCursorDisplayName(C))
$2 = 0x9a5cd0 "RunNumber"
(gdb) p C.
data   kind   xdata
(gdb) set $foo = clang_getCursorDefinition(C)
(gdb) p $foo
$3 = {kind = CXCursor_ClassDecl, xdata = 0, data = {0x7fb39e60e0, 0x1, 0x7fb000cfb0}}

As you can see C != clang_getCursorDefinition(C), because C.data[1] != clang_getCursorDefinition(C).data[1]

clang::cxcursor::operator== (X=..., Y=...)
   at /home/david.abdurachmanov/new-arch/test/BUILD/fc19_aarch64_gcc490/external/llvm/3.4-cms2/llvm-3.4-6800b6d2afc/tools/clang/tools/libclang/CXCursor.cpp:936
936       return X.kind == Y.kind && X.data[0] == Y.data[0] && X.data[1] == Y.data[1] &&
(gdb) info args
X = {kind = CXCursor_ClassDecl, xdata = 0, data = {0x7fb39e60e0, 0x1, 0x7fb000cfb0}}
Y = {kind = CXCursor_ClassDecl, xdata = 0, data = {0x7fb39e60e0, 0x0, 0x7fb000cfb0}}
```

`data[1]` seems to `SourceLocation.ID`.

I compared md5 hashes of `Serialization.cc` files using untouched and modified `condformats_serialization_generate.py`. All were identical.

This is my initial proposal until I understand better the difference in libClang behavior on aarch64 and x86_64, or it's fixed in upstream.