112: Add a method for requesting a form definition

[lindsay-stevens]

Closes #112

What has been done to verify that this works as intended?

Added unit test for the str/bytes code path, and client test to check against Central that the endpoint returns something that looks like XForms XML.

Why is this the best possible solution? Were any other approaches considered?

Follows the same code pattern as forms.get, except for returning a document so pydantic isn't used. An option was included to get the response bytes as-is since this can go to XML parsing libraries like lxml rather than bytes -> str -> parse. For the str/bytes control I considered requiring "encoding='bytes'" but "None" seemed a bit more intuitive in that bytes is not decoded. It could also be true/false flag but then it wouldn't be easy to specify a different encoding and there are some other endpoints that expose encoding options e.g. submissions.create.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Adds a new user-requested endpoint.

Do we need any specific form for testing your changes? If so, please attach one.

N/A existing test fixtures were used.

Does this change require updates to documentation? If so, please file an issue here and include the link below.

No the details are in the docstring.

Before submitting this PR, please make sure you have:

• included test cases for core behavior and edge cases in tests
• run python -m unittest and verified all tests pass
• run ruff format pyodk tests and ruff check pyodk tests to lint code
• verified that any code or assets from external sources are properly credited in comments

[lognaturel]

My apologies for the terrible delay reviewing this!