Implement Serializable in classes we serialize

[grzesiek2010]

Closes #4989

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

I tested the fix manually.

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

I thought about using @Parcelize but it can't be used in non android modules like forms.

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?

It should just fix the issue and have no other effects.

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

No.

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

No.

Before submitting this PR, please make sure you have:

• run ./gradlew checkAll and confirmed all checks still pass OR confirm CircleCI build passes and run ./gradlew connectedDebugAndroidTest locally.
• verified that any code or assets from external sources are properly credited in comments and/or in the about file.
• verified that any new UI elements use theme colors. UI Components Style guidelines

[seadowg]

This is fascinating. I would have thought we'd see a crash when doing args.putSerializable in FormDownloadListActivity. I guess this means that Android isn't actually doing serialization until it needs (when it writes the args to disk during an onSaveInstanceState) which definitely makes sense from a performance point of view, but means it's easy to miss having non-serializable classes in the args hierarchy.

[kkrawczyk123]

Tested with success!
Verified on Androids: 5.1 and 8.1

Verified cases:

• scenario from issue
• crash not visible
• get blank form and dialog are restored
• don't keep activities enabled and disabled
• continue after restoring app

[srujner]

Tested with success!
Verified on Androids: 10 and 11