GeezerVison

The upstream NRF-SDK download url and zip archive filename changed,
which was fixed with #2270

But the archive contents stayed the same, with the "old" folder name.

After #2270 we have basically the same docker-container as before the PR,
but the `GetNrfSdk` function of the `build.sh` script is called again during
firmware build time as the expected foldername for the SDK isn't the same as
the zip filename:

```sh
[ ! -d "$TOOLS_DIR/$NRF_SDK_VER" ] && GetNrfSdk
```

Then during the build the `buils.sh` script tries to execute `GetNrfSdk` again,
which fails as the files already exist resulting in the following error:

```
replace /opt/nRF5_SDK_15.3.0_59ac345/components/802_15_4/api/HAL/hal_atomic.h? [y]es, [n]o, [A]ll, [N]one, [r]ename:  NULL
```

Fix this by reverting the `NRF_SDK_VER` to the folder name in the zip
archive and by some character replacement generate the download URL from
the above (the download is in lower-case without the `_` and `.`
characters).

Furthermore add safeguards to check after the `GetNrfSdk` call if the
expected folder is really created. Then we have an error early during
container image creation if the contents of the zip-archive are
unexpected.

The upstream NRF-SDK download url and zip archive filename changed,
which was fixed with #2270

But the archive contents stayed the same, with the "old" folder name.

After #2270 we have basically the same docker-container as before the PR,
but the `GetNrfSdk` function of the `build.sh` script is called again during
firmware build time as the expected foldername for the SDK isn't the same as
the zip filename:

```sh
[ ! -d "$TOOLS_DIR/$NRF_SDK_VER" ] && GetNrfSdk
```

Then during the build the `buils.sh` script tries to execute `GetNrfSdk` again,
which fails as the files already exist resulting in the following error:

```
replace /opt/nRF5_SDK_15.3.0_59ac345/components/802_15_4/api/HAL/hal_atomic.h? [y]es, [n]o, [A]ll, [N]one, [r]ename:  NULL
```

Fix this by reverting the `NRF_SDK_VER` to the folder name in the zip
archive and by some character replacement generate the download URL from
the above (the download is in lower-case without the `_` and `.`
characters).

Furthermore add safeguards to check after the `GetNrfSdk` call if the
expected folder is really created. Then we have an error early during
container image creation if the contents of the zip-archive are
unexpected.

nRF has moved the download to a new location- Update the build script to fetch from the same URL the download website currently provides.

)

The upstream NRF-SDK download url and zip archive filename changed,
which was fixed with InfiniTimeOrg#2270

But the archive contents stayed the same, with the "old" folder name.

After InfiniTimeOrg#2270 we have basically the same docker-container as before the PR,
but the `GetNrfSdk` function of the `build.sh` script is called again during
firmware build time as the expected foldername for the SDK isn't the same as
the zip filename:

```sh
[ ! -d "$TOOLS_DIR/$NRF_SDK_VER" ] && GetNrfSdk
```

Then during the build the `buils.sh` script tries to execute `GetNrfSdk` again,
which fails as the files already exist resulting in the following error:

```
replace /opt/nRF5_SDK_15.3.0_59ac345/components/802_15_4/api/HAL/hal_atomic.h? [y]es, [n]o, [A]ll, [N]one, [r]ename:  NULL
```

Fix this by reverting the `NRF_SDK_VER` to the folder name in the zip
archive and by some character replacement generate the download URL from
the above (the download is in lower-case without the `_` and `.`
characters).

Furthermore add safeguards to check after the `GetNrfSdk` call if the
expected folder is really created. Then we have an error early during
container image creation if the contents of the zip-archive are
unexpected.