Make the CRC Platform Abstraction Layer multi-context-safe

[parmi93]

• Introduces stse_crc16_context_t struct context.
• Introduces stse_platform_Crc16_ContextInit() and stse_platform_Crc16_ContextRelease() PAL APIs.
• Refactors stse_platform_Crc16_Accumulate() PAL API.
• Removes stse_platform_Crc16_Calculate() PAL API.

These changes resolve issue #65 by allowing users to adapt the CRC16 PAL implementation to scenarios where communication with multiple STSAFE devices takes place concurrently.

Additionally, they make it possible to implement thread-safe CRC16 PAL APIs when CRC computation is performed by a shared hardware peripheral. This ensures that concurrent access from multiple threads can be managed safely, even when those threads are not necessarily communicating with different STSAFE devices.

[parmi93]

I just realized that this PR targets the main branch instead of dev/1.2.0. I can't find an option to change the target branch on my side, so hopefully one of the maintainers has the necessary permissions to update it.

[TofMassilia13320]

Tx to solve conflicts.
I see:

• multiple crc init
• stse_platform_Crc16_Calculate presence

[parmi93]

Fix the conflicts by rebasing my branch (dev/1.2.0) with the upstream/dev/1.2.0 branch, and I push forced to keep the git history clean.

[parmi93]

@TofMassilia13320 I noticed you force-pushed these 2 commits a couple of days ago onto the upstream dev/1.2.0 branch:

• [fix][services] use STSAFE family index [237f4d9]
• [docs][api] add documentation for generate key behaviour [111bf16]

This rewrote the commit history for the last 3 weeks. Just a suggestion: as a general rule, I only force-push on my own forks where I'm the sole person working, and I avoid it on upstream branches shared by multiple developers, since it rewrites shared history. Anyone who has already pulled or branched off the old commits ends up with diverging history and has to manually reconcile or reset to match the new one.

Force-pushing on an upstream branch usually makes sense when you need to remove something sensitive from history, like leaked credentials, secrets, or accidentally committed files, where rewriting history is actually necessary. For regular fixes or updates, though. Pushing new commits on top, rather than rewriting old ones, would prevent this issue for anyone else working off this branch.

[TofMassilia13320]

@parmi93,
You're true. History was rewritten because I've rebased and merged the dev/1.2.0 on the main branch.
I didn't catch you were developing using this 1.2.0branch even if if it was not validated... and I wasn't align with the right management of this dev/1.2.0 branch.
We decided yesterday to now cherry pick each interesting commit from main branch instead of rebasing.
Sorry for this inconvenience.