Inconsistent handling of bootstrap_packages path in _read_profile()

Description:

When defining a custom bootstrap_packages file in profiledef.sh, the path must always be absolute or relative to the current working directory (i.e., where mkarchiso is executed). In contrast, the packages variable can be set to a filename like packages=packages.$arch, and _read_profile() correctly resolves it relative to the profile directory.

This inconsistency means that defining bootstrap_packages=bootstrap_packages.$arch will not work unless the file is in the working directory. To make it work as if it were relative to profiledef.sh, the user must explicitly set:

bootstrap_packages=$profile/bootstrap_packages.$arch

This differs from how packages is handled, making profile definitions less intuitive and harder to port or reuse.

Steps to reproduce:

1. In profiledef.sh, set:

   bootstrap_packages=bootstrap_packages.$arch

2. Place the file in the same directory as profiledef.sh

3. Run mkarchiso -v -w work -o out .

4. The script fails because it tries to resolve the path from the working directory, not from the profile directory.

Expected behavior:

Paths given in profiledef.sh for bootstrap_packages should be resolved relative to the profile directory, just like packages, unless they are absolute.

Proposed fix:

In _read_profile(), resolve the path for user-defined bootstrap_packages if it is non-empty, similar to how packages is handled:

[[ -n "$bootstrap_packages" ]] && bootstrap_packages="$(realpath -- "${bootstrap_packages}")"

Alternatively, treat all non-absolute bootstrap_packages paths as relative to $profile.