UX_SLAVE_CLASS_STORAGE_LUN.ux_slave_class_storage_media_id is never initialized or set, but it is dereferenced

[nflandin]

Describe the bug
The "UX_SLAVE_CLASS_STORAGE_LUN" struct has a member called "ux_slave_class_storage_media_id", which is not initialized, and cannot be set via the API, but is de-referenced and passed into (the same struct's) "ux_slave_class_storage_disk_status" function.

Please also mention any information which could help others to understand
the problem you're facing:

• This issue relates to all devices
• Seems to have originated at some point before 6.3.0
• This issue relates to all toolchains and environments
• Issue is fully characterized

To Reproduce
Steps to reproduce the behavior:

1. _ux_device_class_storage_initialize stores all the application parameter information about the media in the UX_SLAVE_CLASS_STORAGE_LUN struct, except for ux_slave_class_storage_media_id, which is completely uninitialized (i.e. is garbage).
2. The garbage value is then passed into ux_slave_class_storage_disk_status, for no clear reason, as that function could easily have obtained the (garbage) by simply using its second parameter to de-reference its first.
3. There is no known "error", only waste.

Expected behavior
I would expect that _ux_device_class_storage_initialize would set this member as per the 'parameter' passed into _ux_device_stack_class_register, or that the member would not exist at all.

Impact
This issue wastes four bytes per UX_MAX_SLAVE_CLASS_DRIVER, and increases stack utilization by four bytes (in ux_slave_class_storage_disk_status calls).

Logs and console output
N/A

Additional context
I suspect that the struct member was introduced by the original development team to enable some functionality which was either later removed, or only used in a few customer applications

[fdesbiens]

Thank you for raising this issue, @nflandin.

@rahmanih: Can you take a look, please?