Update developer documentation to explain how to use backend code

[mikehardy]

proto classes are (were?) difficult to construct from inside Java, making testing and mocking difficult

With the Kotlin extensions, creation is quite easy. Currently the only proto message in DeckPicker is OpChanges, and you could create an instance of that with the studyQueues field set using something like the following:

        val changes = opChanges {
            studyQueues = true
        }

classes were not well documented due to being autogenerated

That is true, the code protobuf-java generates does not make it very easy to see at a glance which fields are available. It does take comments from the .proto files and include them in docstrings, but those docstrings get stripped from the .class files included in the artifact. I presume Google expect people to be referencing the .proto files when they work with generated messages, and it is clearer that way, as you can see at a glance what methods are available in a given category, and how the messages relate to each other.

Originally posted by @dae in #11644 (comment)

[github-actions]

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically