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>
```
I cant find any other uses for it. These methods were all part of SAMLUtils before. There is a `return Base64.encodeBase64String(output);` call. It seems like it would make sense for us to encapsulate base64 encoding logic somewhere once and have it be used elsewhere. There are many other Base64 references in the code. Sounds like a reasonable pull to me.