Some machines have read-only vtables but this test expects to overwrite
them. Use -no_data_const to ensure the vtable is writable

If this test fails, you're likely going to see something like "Assertion
Error: A != B" which doesn't really give much explanation for why this
failed.

Instead of ignoring the error, we should assert that it succeeded. This
will lead to a better error message, for example:
`AssertionError: 'memory write failed for 0x102d7c018' is not success`

assertEquals is a deprecated alias for assertEqual and has been removed
in Python 3.12. This wasn't an issue previously because we used a
vendored version of the unittest module. Now that we use the built-in
version this gets updated together with the Python version used to run
the test suite.

This failed on the public LLDB matrix build bots on Clang versions <
9.0:
```
======================================================================
FAIL: test_base_class_ptr (TestVTableValue.TestVTableValue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "lldb/test/API/functionalities/vtable/TestVTableValue.py", line 90, in test_base_class_ptr
    self.assertEquals(shape_ptr_vtable.GetNumChildren(), 5)
AssertionError: 6 != 5
```

This fails on the matrix build bot for Clang versions < 9.0


https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-matrix/7309/execution/node/102/log/?consoleFull

```
FAIL: LLDB :: test_vtable (TestVTableValue.TestVTableValue)
<bound method SBProcess.Kill of SBProcess: pid = 35338, state = stopped, threads = 1, executable = a.out>: success

======================================================================
FAIL: test_base_class_ptr (TestVTableValue.TestVTableValue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "lldb/test/API/functionalities/vtable/TestVTableValue.py", line 90, in test_base_class_ptr
    self.assertEquals(shape_ptr_vtable.GetNumChildren(), 5)
AssertionError: 6 != 5
======================================================================
FAIL: test_vtable (TestVTableValue.TestVTableValue)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "lldb/test/API/functionalities/vtable/TestVTableValue.py", line 67, in test_vtable
    self.assertEquals(vtable.GetNumChildren(), 5)
AssertionError: 6 != 5
----------------------------------------------------------------------
Ran 4 tests in 2.799s

RESULT: FAILED (2 passes, 2 failures, 0 errors, 0 skipped, 0 expected failures, 0 unexpected successes)
```

7fbd427f5ebea4a4ebf25747758851875bb7e173 added a test that overwrites
a vtable entry but it uses and expects a 64 bit value. Add the 32 bit
equivalents.

Add the ability to get a C++ vtable ValueObject from another
ValueObject.

This patch adds the ability to ask a ValueObject for a ValueObject that
represents the virtual function table for a C++ class. If the
ValueObject is not a C++ class with a vtable, a valid ValueObject value
will be returned that contains an appropriate error. If it is successful
a valid ValueObject that represents vtable will be returned. The
ValueObject that is returned will have a name that matches the demangled
value for a C++ vtable mangled name like "vtable for <class-name>". It
will have N children, one for each virtual function pointer. Each
child's value is the function pointer itself, the summary is the
symbolication of this function pointer, and the type will be a valid
function pointer from the debug info if there is debug information
corresponding to the virtual function pointer.

The vtable SBValue will have the following:
- SBValue::GetName() returns "vtable for <class>"
- SBValue::GetValue() returns a string representation of the vtable
address
- SBValue::GetSummary() returns NULL
- SBValue::GetType() returns a type appropriate for a uintptr_t type for
the current process
- SBValue::GetLoadAddress() returns the address of the vtable adderess
- SBValue::GetValueAsUnsigned(...) returns the vtable address
- SBValue::GetNumChildren() returns the number of virtual function
pointers in the vtable
- SBValue::GetChildAtIndex(...) returns a SBValue that represents a
virtual function pointer

The child SBValue objects that represent a virtual function pointer has
the following values:
- SBValue::GetName() returns "[%u]" where %u is the vtable function
pointer index
- SBValue::GetValue() returns a string representation of the virtual
function pointer
- SBValue::GetSummary() returns a symbolicated respresentation of the
virtual function pointer
- SBValue::GetType() returns the function prototype type if there is
debug info, or a generic funtion prototype if there is no debug info
- SBValue::GetLoadAddress() returns the address of the virtual function
pointer
- SBValue::GetValueAsUnsigned(...) returns the virtual function pointer
- SBValue::GetNumChildren() returns 0
- SBValue::GetChildAtIndex(...) returns invalid SBValue for any index

Examples of using this API via python:

```
(lldb) script vtable = lldb.frame.FindVariable("shape_ptr").GetVTable()
(lldb) script vtable
vtable for Shape = 0x0000000100004088 {
  [0] = 0x0000000100003d20 a.out`Shape::~Shape() at main.cpp:3
  [1] = 0x0000000100003e4c a.out`Shape::~Shape() at main.cpp:3
  [2] = 0x0000000100003e7c a.out`Shape::area() at main.cpp:4
  [3] = 0x0000000100003e3c a.out`Shape::optional() at main.cpp:7
}
(lldb) script c = vtable.GetChildAtIndex(0)
(lldb) script c
(void ()) [0] = 0x0000000100003d20 a.out`Shape::~Shape() at main.cpp:3
```