Adding Iterator and rename functions

[MarcusJGStreets]

Added in PS storage initially. If thee is need for them in ITS, the same additions can be made there

[athoelke]

The merge of main back into this branch has no effect because Git believes that the relevant changes have previously been merged, and this branch has then made changes after that merge.

To repair the inadvertent 'revert' changes to some of the source files will require more effort.

• You could add a new commit to change them back to the current content on main. That isn't ideal in terms of history, but it works.
• Otherwise you need to find the commits in the current branch that introduce those changes, and then edit those commits to no longer do so. An interactive rebase can make that process a bit easier.
• Or start with the first option, then use an interactive rebase to move the 'fix' commit immediately after the commit that makes the incorrect change, and mark it as 'fixup' in the interactive rebase file.

[MarcusJGStreets]

Added in PS storage initially. If thee is need for them in ITS, the same additions can be made there

Now added to ITS

[MarcusJGStreets]

Updates with clarifications that iterator start returns a pointer to a new context. And split the support iterator macro into ITS and PS for compile time detection.

[athoelke]

While working through the issues for this addition: I wonder if we should improve the text for the optional 1.0 functions psa_ps_create() and psa_ps_set_extended()?

The current wording is not clear whether an implementation that does not support these functions must provide definitions of them in a header file (perhaps with inline implementations), and so ensure that an application that references these functions will compile?

What does TF-M do?