dcache-webadmin: fix login redirect bug which misleadingly results in Access Denied Page

The following sequence of actions results in an Access Denied Page:

1.  Click on a bookmarked webadmin page (\*\*\* but see Testing below).
2.  On the user panel (below the DCache Bird at far right top),
    click login.
3.  Fill in user/password in login page, and click login.

The problem, which actually exists since Wicket 1.5, is that
the return URL used by Wicket to redirect from the intercept
page actually contains, as its query part, the subcomponent
of the page that generated the intercept request.

The problem is benign because returning to the home page
after the Access Denied Page appears shows that the user
is properly logged in.

In order to maintain correct redirection after intercept,
the only choice seems to be to override the exception-handling
pattern which Wicket uses to control the destination,
and to then force the reset of the target response page.

This is enabled by exposing the previously unexposed constructor
for the BasePage which allows PageParameters to be passed in,
and determining the bookmarked page class from the first
parameter.  If none is set, it then defaults to the home
page, as before.  In order to redirect with to an intercept
page, the RestartResponseAtInterceptPageException thrown
for this purpose should thus be constructed with the log in
page class and page parameters.

At present I cannot determine if there are any preferred
workarounds for this.  The problem presented at this link:

http://apache-wicket.1842946.n4.nabble.com/RestartResponseAtInterceptPageException-problem-in-1-5-td4255020.html

is precisely the one at issue here, but the suggestion
made by the developer is irrelevant.

This bug has actually been present since we migrated from
1.4 to 1.5, but has gone undiscovered until now (or at
least unreported).  Jan's and Tanja's code undoubtedly worked
correctly in the pre-1.5 context in which it was originally
written.

Target: 2.8
Committed: 39c2c0ebc16d97c1446c11c4a7a77c0d4862228f
Acked-by: Tigran
Patch: http://rb.dcache.org/r/6987
Bug: http://rt.dcache.org/Ticket/Display.html?id=8266
Require-book: no
Require-notes: yes

RELEASE NOTES:  Fixes a bug where clicking the login link from the
dCache bird panel on webadmin pages and then signing in via the
login page brings up an Access Denied Page (but which nonetheless
results in the user being properly logged after having
navigated to the home page).

TESTING:

***It is best to use a non-admin page to test this.
The reason is that currently, multiple gids are not
supported for administration access, and unless the
user cert is directly mapped to the admin user, navigating
to an admin page results in an automatic sign-in
via the cert; the user then is required to log out
and log in as admin, so the final response page in
this case is actually the log in page. The problem
of multiple gids will need to be addressed in the future.

After application of this patch, the Access Denied page
no longer appears and the user is redirected back to the
original page after login.
Merge pull request #611 from alrossi/fix/2.8/webadmin-login

Fix/2.8/webadmin login