Draft: Make all Rust references const.

This replaces all &mut self references on the Rust side with &self. See https://bugs.kde.org/show_bug.cgi?id=448087 for details.

To facilitate this, the following additional restrictions have been imposed:

• Rust-By-Function is now the only way to return String and Byte-Array properties. The respective JSON option has been removed. This is because it is generally not possible to return a reference out of an immutable context. Returning owned values would work, but would quite often impose the overhead of an additional copy, while rust-by-function has negligible overhead (I expect the function to be auto-inlined, so overhead would be near-zero) and is just slightly more verbose.
• Similarly Rust-By-Value has been removed. Item-Properties use Rust-By-Function now for String and Byte-Array properties, and both owned types (String, Vec) support auto Dereference into slices.
• Mutable functions have been removed.

In addition, the unfinished (or broken) support for writeable object-properties has been disabled. The writeable flag is now silently ignored for object properties, instead of generating non-compiling C++ and no Rust code. It can be re-enabled by removing all the && !p.is_object() conditions that have been added to cpp.rs in soulsource/rust-qt-binding-generator@31b3ef54.

The generator for initial implementation.rs files has been updated to wrap everything in RefCell. In addition it adds a comment that in multithreaded contexts one would probably want to use something thread-safe, like a Mutex.

All tests have been updated. Except for the test for functions the implementation.rs files have been replaced by auto-generated versions as well, to test the changes to the generator for implementation.rs. The function test was excluded here, as no functions are generated by the automatic implementation. All required test-data has been re-added by hand after the re-generation.

Edit: An additional change has been made, namely that the computation of the QModelIndex from the newDataReady() signal has been moved from the sending to the receiving side. In situations where the previous code actually worked, the change should not cause any noticeable effect. Computing the index on the receiving side however fixes the issue that its row-index might have gone stale between sending the signal and handling it in the UI thread (assuming that the internal ID of tree elements is stable, but that's also a requirement of the previous code). See 85cfc12b for details.

Edit 2: Actually I've now removed the computation of row indices when sending newDataReady(), and just pass in a row index of 0. It is anyhow ignored by the auto-generated fetchMore() code, so computing it is just an additional point of potential failure with (I think) no additional gain.