bt2: field.py: numeric classes: remove __i*__ operators

bt2: field.py: numeric classes: remove __i*__ operators

Those operators do a binary operation to a field object and another
operand, and then set the result as the field object's value.

Now that I think about it, it is weird to do something like:

    my_int_field += 17.5

and that, when the value of `my_int_field` was 23, its value after the
operation becomes 40. This is not a problem for a native Python object
because `a` does not name the same object after the operation:

    a = 23
    type(a)     # int
    id(a)       # 140669243488160
    a += 17.5
    type(a)     # float
    id(a)       # 140669043054920

but we can't do this with our field object: this is internal Python's
magic.

So I believe we should be more strict. But this means you can't do:

    my_int_field += 17.5

anymore (a `TypeError` exception would be raised).

This means a lot of specific automatically injected tests must
conditionally exist (depending on whether or not the test is possible
with the two operands, whereas it's always possible now).

Instead of doing this work, I choose to completely remove the support
for "self" operators. We can add useful ones in the future when we have
time, but I don't even think they are super useful: because a field
object becomes conceptually frozen as soon as you emit a message which
owns it indirectly, there's no point in doing `+=`, `-=`, `**=`, `<<=`,
and so on. For those rare cases, you can always do:

    my_int_field = my_int_field + 17

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
Change-Id: I5410ff8fdb2c3a1910e788542376d521601fdf8f
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1568
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Reviewed-by: Simon Marchi <simon.marchi@efficios.com>