tests: Made pointer parameters explicitely const where non-const pointer parameters are not needed

[DeHess]

modified parameter types to receive a const pointer when a non-const pointer is not needed

This corresponds to following misra coding guideline:

A cast shall not remove any const or volatile qualification from the type pointed to by a pointer

This PR is part of the enhancement issue #48002 which port the coding guideline fixes done by BUGSENG on the https://github.com/zephyrproject-rtos/zephyr/tree/v2.7-auditable-branch back to main

The commit in this PR is a subset of the original auditable-branch commit:
f953e92

[npitre]

You changed:

-       zassert_true(arch_buffer_validate((void *)&__ramfunc_start,
+       zassert_true(arch_buffer_validate((const void *)&__ramfunc_start,

How this can even not produce a warning given that arch_buffer_validate()
is declared with a plain (not const) void pointer? Maybe it is
arch_buffer_validate() that ought to qualify its argument as const as
it is not supposed to alter the buffer's content.

Also the original cast is probably redundant and could be removed
altogether.

[andyross]

Let's not do const-correctness piecewise. Const goes on function arguments and struct fields first, then propagates outwards as needed. Declaring local variables const is at best providing some tiny bit of safety in a single function, and as @npitre points out the cast on that pointer is just a noop as the argument is non-const.

[DeHess]

@andyross , @npitre

You are right, i was planning on adding const thing seperately across the different modules of the project.

I admit it was never ideal.

As it turns out, it might be possible to remove the arch_buffer_validate method entirely, as it does not seem to be in use anymore.
For this pr, I just removed the change for the validate method.

[andyross]

Still seems silly to have a whole PR just to flag one local variable const in a random test, but no reason not to approve I guess.