Adding X-Forwarded-Proto support

This issue was reported originally here https://bugs.dokuwiki.org/index.php?do=details&task_id=2928

I'm running dokuwiki on apache, not exposed directly to external requests. Nginx is used as a reverse proxy and also adds SSL. Since the network between nginx and apache is considered secure (never leaves the host), no SSL is applied on apache side. Every request to apache is made over plain HTTP.

When saving a page after an edit or when hitting cancel the user is currently redirected to HTTP from HTTPS. The problem here is to edit the page you must be authenticated and so I configured nginx to force HTTPS for the authentication:

```
location /dokuwiki {
        # redirect to https for login and admin
        if ($args ~* do=(log|admin|profile)) {
                rewrite ^ https://$host$request_uri? redirect;
        }

        proxy_pass http://localhost:80;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
}
```

when authenticated a user should stay on HTTPS, but HTTPS cannot be enforced for every page, since anonymous access can happen via HTTP, nothing wrong with that. And anyway one less redirect is a good thing.

If I understood well the problem begins in the inc/actions.php

```
function act_redirect_execute($opts){
        $go = wl($opts['id'],'',true);
        if(isset($opts['fragment'])) $go .= '#'.$opts['fragment'];

        //show it
        send_redirect($go);
}
```

the third argument to wl is true, so the redirect is absolute and wl() will use DOKU_URL as a starting point. I don't set DOKU_URL, so dokuwiki is autodetecting.

The getBaseURL function works as expected in building the URL except for the protocol used, which is http and not https. Https is used only if is_ssl returns true.

is_ssl() should check for X-Forwarded-Proto header (and likely also for Front-End-Https) to evaluate if ssl should be used or not. Another solution can be doing the redirect relative instead of absolute in act_redirect_execute, but I have no idea if this can have some unwanted collateral effect.
Keeping those 2 lines will result in trying an HTTPS connection over port 80. The apache backend is serving the request via HTTP, thus listening on port 80 --> $_SERVER['SERVER_PORT'] == 80. The reverse proxy / load balancer / ssl accelerator uses 443.

I don't see the point of that code (for my very limited use case at least), and wrapping it into an
`if(isset($_SERVER['HTTP_X_FORWARDED_PROTO']))` was not looking great to me.