Define directories that the runtime might access and assign to user if present

The Functions runtime might interact with a local file system for various behaviors. Today, this is fine if the container user is root. However, if a container user is set, they would hit an error when that file access is attempted. For example, the following can occur with the sentinel file for the secrets provider:

> System.UnauthorizedAccessException: Access to the path '/azure-functions-host/Secrets' is denied. ---> System.IO.IOException: Permission denied

The images should define the directories that are writeable by the runtime and chown them to the container user.

A specific path through which this was encountered is when using SDK container builds for .NET. Notes (adapted from those of @fabiocav):

- The [ASP.NET Core base image](https://github.com/dotnet/dotnet-docker/blob/3e50a8fa50c86e0863b95f332379be30e2943d74/src/runtime-deps/9.0/bookworm-slim/amd64/Dockerfile#L5) sets the APP_UID environment variable. This means our images include `APP_UID` as well.
- The .NET SDK, when doing an SDK container build, will look for that environment variable. If present, it [sets it as the container user](https://github.com/dotnet/sdk/blob/6281db04c2064c20a3d0f6ee903d1065ff8f37bf/src/Containers/Microsoft.NET.Build.Containers/ImageBuilder.cs#L251-L262).
- The resulting image will then have a specified container user, and that user will not have access to the file system paths expected.

To get around this, one could reset the user to root by adding `` into the .NET project file, though that wouldn't be our recommendation - it's just a workaround for demonstrating the behavior. Instead, we should ensure our images are just resilient to having a user set. It would also be a best practice in general to set a lower privilege user for the base images made available to customers.

I understand `APP_UID` to be a standard practice, though I don't know the specifics / if there are competing alternatives. But at the very least we could start by just checking to see if this is set, and if it is, doing the chown.

We'll need to put together a list of paths of interest as a part of this work.

No specific files or tests are named. Start by reviewing the repository's image Dockerfiles and identifying the local paths the Functions runtime may write to, including /azure-functions-host/Secrets. Done means images remain usable when APP_UID or another container user is set, with the identified writable directories assigned to that user.

Written by the indexing model from the issue text.