Add comment (sailfishos-patches#358)

* Add comment
  … which answers my …
  #### QUESTION
  Which patch file to backup after 32-/64-bit mangling [in line 183 of `pm_apply`](https://github.com/sailfishos-patches/patchmanager/blob/master/src/tools/pm_apply#L183)?
  #### ADDITIONAL INFORMATION
  I stumbled across this, because usually [the variable `PATCH_PATH="$PATCH_DIR/$PATCH_NAME"` (line 23)](https://github.com/sailfishos-patches/patchmanager/blob/master/src/tools/pm_apply#L23) should be used in aforementioned line 183 of the [function `create_backup_patch`](https://github.com/sailfishos-patches/patchmanager/blob/master/src/tools/pm_apply#L175-L186), instead of using `"$PATCH_DIR/$PATCH_NAME"`.
  But when asking myself, if this may be done on purpose (i.e., if this makes a difference), I think it does, if the mangling became active, but had no idea if this was intentional.
  * `PATCH_PATH="$PATCH_DIR/$PATCH_NAME"` is set early (in line 23), so it contains the original Patch name as `PATCH_DIR` and always `PATCH_NAME="unified_diff.patch"`.
  * If the mangling was performed successfully, [`PATCH_PATH="$patch_edited_path"` (line 143)](https://github.com/sailfishos-patches/patchmanager/blob/master/src/tools/pm_apply#L143) with [patch_edited_path="$PM_PATCH_BACKUP_DIR"/"$PATCH_EDITED_NAME" (line 130)](https://github.com/sailfishos-patches/patchmanager/blob/master/src/tools/pm_apply#L130).  Hence … [see new comment]

  … yes, this was intentional, but I forgot why after a year.  Thus documenting in a comment.

src/tools/pm_apply

@@ -180,6 +180,8 @@ create_backup_patch() {
   log
 
   mkdir -p "$PM_PATCH_BACKUP_DIR" > /dev/null 2>&1
+  # Backup the original patch file, NOT $PATCH_PATH, which might be altered by 32-/64-bit mangling in line 143.
+  # If mangling was performed successfully, it already wrote its patched $PATCH_EDITED_NAME to $PM_PATCH_BACKUP_DIR in line 134.
   cp -f "$PATCH_DIR/$PATCH_NAME" "$PM_PATCH_BACKUP_DIR" > /dev/null 2>&1
   log "Created backup: $PM_PATCH_BACKUP_DIR"
   log