GoogleService: SAML response refactoring

Currently, the `GoogleAccountsService` attempts to produce and sign a saml response that is directly hardcoded into the class while our other saml-related components use opensaml to do the job.  This pull pursues the following objectives:

## Goals
* Remove the hardcoded response from `GoogleAccountsService`, allow saml2 response to be generated by opensaml instead
* Remove hardcoded constants and move them into constants interfaces
* Allows the saml2 response for google to be modified and extended
* Allows future SAML2-requiring apps to take advantage of extensibility options
* Still ensures that the saml2 response is Google specific (that is not always 100% pure saml) wrt namespaces, prefixes, etc. 

## How

* Removed `SamlUtils`
* Adds `AbstractSamlObjectBuilder` which is the combination of `SamlUtils` and the SAML-stuff put into the `AbstractSaml10ResponseView` class. This class is the most generic parent, with no ties or dependencies to saml1 or saml2. 

Then there are:

* `Saml10ObjectBuilder`: builds saml1 specific functionality via opensaml
* `Saml20ObjectBuilder`: builds saml2 specific functionality via opensaml
* `GoogleSaml20ObjectBuilder`: builds saml2 specific to google functionality via opensaml

`GoogleAccountsService` as well as other saml components use a proper builder instance to do the job.

## Result
Generated response is the same as before:

```xml
<?xml version="1.0" encoding="UTF-8"?>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" ID="pecacnijhcaapmjgeigccngjckmpaejinhhmoajk" IssueInstant="2014-11-08T09:19:50.000Z" Version="2.0">
   <samlp:Status>
      <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
   </samlp:Status>
   <Assertion ID="cnpllfpbgkojdgboikngilhcndbhmojjfnkjmllb" IssueInstant="2003-04-17T00:46:02.000Z" Version="2.0">
      <Issuer>https://www.opensaml.org/IDP</Issuer>
      <Subject>
         <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">test</NameID>
         <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
            <SubjectConfirmationData InResponseTo="5545454455" NotOnOrAfter="2014-11-08T09:19:50.000Z" Recipient="https://localhost:8443/myRutgers" />
         </SubjectConfirmation>
      </Subject>
      <Conditions NotBefore="2003-04-17T00:46:02.000Z" NotOnOrAfter="2014-11-08T09:19:50.000Z">
         <AudienceRestriction>
            <Audience>https://localhost:8443/myRutgers</Audience>
         </AudienceRestriction>
      </Conditions>
      <AuthnStatement AuthnInstant="2014-11-08T09:19:50.000Z">
         <AuthnContext>
            <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
         </AuthnContext>
      </AuthnStatement>
   </Assertion>
</samlp:Response>
```
It looks like a method which has a wider scope than just SAML. I would be surprised that we don't use that somewhere else (in the logout manager for example).