refactor: replace ARGS_ with ARG_, standardize requireParcelable usage

[ericli3690]

Note

Assisted-by: Composer 2.5 (for ARG_ renaming grunt work)

Purpose / Description

Per the naming conventions we've decided on, argument constant names should begin with ARG_, not ARGS_. This change standardizes instances of ARGS_ I found in the codebase. I initially tried applying the change to all argument constants in the entire repo, but as you can guess that spiralled out of control really fast. To keep the scope limited and safe, I've just looked for all instances of "ARGS_", plus any files I've touched, and fixed those.

Also, at #19896, David suggested using requireParcelable more. I find the utility functions in BundleUtils very useful and have applied them everywhere possible after looking for instances of requireNotNull in the codebase. This includes two review reminder instances.

Fixes

• Part of discussion: Document & enforce naming conventions [layouts/standard variables] #19896
• Addresses some small feedback at feat(reminders): streamline review reminders UI #21140

Approach

Renaming PR, followed by the standardization of requireParcelable, requireString, etc.
There were some requireNotNull instances that grabbed things like string arrays and long arrays from Bundles: no such utility function to handle these cases exists yet in BundleUtils so I just left those as is. Could be something to return to in the future, but this is very low priority.

I also believe it is better to use lazy to get stored arguments rather than defining a get() = to avoid re-computation of something that never changes.

Overall, after applying requireParcelable and lazy, I personally think a lot of argument usages are now cleaner.

How Has This Been Tested?

• App builds
• Unit tests pass
• Card browser and note editor works: editing cards, moving columns, selecting columns, search, tags search, adding fields
• Review reminders can be edited, deleted (includes confirmation dialog); notification permission requests work

Checklist

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code

[david-allison]

This could have an extension to be cleaner

[ericli3690]

Hm sorry, not sure what you mean / are envisioning here. Do you want to create something similar to BundleUtil's helper functions for SavedStateHandles, too? Something like SavedStateHandleUtil.kt and "requireSavedStateKey"? That's a bit overkill / out of scope for this PR in my opinion, this is probably fine for now. Unless you meant something else?

[david-allison]

Merge at your discretion, might warrant a second Reviewer as I'm unsure of the test coverage here

[ericli3690]

Let's wait for one more reviewer just in case! Thanks for the quick review :)

[criticalAY]

LGTM