Remove files dealing exclusively with DevPay.

Signed-off-by: Daira Hopwood <daira@leastauthority.com>
Remove customer name from confirmation and tests.

We only used it in the salutation in the confirmation email.
We don't need to ask Users for an ID apart from their CC#
and email address.

The variable is not yet completely removed.  Other
references to it will be removed within larger changes to
the signup flow.
Redefine LoggingTeeStream to LoggingStream

We don't need it to Tee.
Updates to the html templates.

Name redirections reflect the new naming schemes for stripe
signup.

Several tweeks by daira to improve rendering/security, that I don't
totally understand.
daira cleans up css
Adds framework for js unittesting.
Add payment form and js handling logic

Note this commit does not register the form
with a twisted web server resource, so it
will not produce an interactive page if you
run the site.
Update initialization of handlers.
Add Stripe-Webserver-Component

Not core Stripe functionality:

* emailcollector.py:  functionality migrated out of "devpaycomplete" module
which was removed
* handlers/main.py :  functionality common to mutiple handlers, also migrated out of "devpaycomplete" removed module
* lae_site/main.py:  enhanced logging, proper (Stripe-not-devpay) names

Core Stripe functionality:
(1) submit_subscription.py:
    -- function 'start':  Sets up flappservice as a global variable during webserver startup
    -- SubmitSubscriptionHandler:
       (1) Sets up logging bound to the module and Class "SubmitSubscriptionHandler"
       (2) Receives an HTTP message as result of $form.get(0).submit:
          line 45 subscription_signup.js
       (3) Parses arguments out using "get_arg":
          line 41 handlers/main.py
       (4) Uses UID from Stripe bound to a customer credit card: line 44
           AND
           Our Private Stripe API Key: line 50
           to create a customer object in the stripe DB and subscribe that
           customer to our S4 plan:  line 54
       (5) Upon an exception renders the subscription form and returns it to the browser
       (6) Appends new customer-subscription-to-plan UID to a local (webserver) log: line 64
       (7) Ensures data is ascii/JSON: line 81
       (7.1) Registers callbacks
       (8) Sends the data to the provisioning service (async): line 89
       (9) Renders a "payment verified" html and sends that to the browser

(2) templates/payment_verified.html:  HTML which is sent to the browser.  Text informs the User that
their card was successfully processed and the service is being created.
begin html non-code commit
Update all jasmine tests, and js Code Under Test

This commit is regrettably huge.
After its application, the JS and associated
unittests are in the 'current' 2014-03-11
state.

While the commit itself is like too large to facilitate
easy review, the associated unittests are quite verbose.

To run the unitests, load:

content/static/js/test/unit/runner.html
Kill hanging flappservice signups after 2 hours.

daira wrote this IIRC
Completes changes to the "front end" html, js.

Updates the subscription form in various ways.
The HTML now conforms the html spec (vise xml) with
the removal of closing '/'s.
CVCs can now be 3 or 4 chars
Useful information for the browser in the case of
a rendering failure. etc.
Adds support for core functionality in signup

(1) fileutil, as in allmydata util, implement idempotent dir creation
(2) FlappCommand.run returns a deferred, call/err-backs are to be added
by the caller (in this case SubmitSubscriptionHandler.render)
(3) A change in the return type of parse caused an unexpected test
failure.  This commit handles both types gracefully.
Update tests for new form of FlappCommand.run
Add functionality for handling stripe messages

NOTE: submission of data from the User's
browser to stripe is handled by the previously
committed "subscription_signup.js".  Unittests
for that code are also in an ancestral commit.

Note: non-solvent payment credentials, cause stripe servers
to send a message to the browser.
Note: invalid submission data, e.g. wrong type of CC, is
handled in browser by our html/and-or stripe.js.

This handler is invoked when:
(1) The User's payment (cc) information has been
processed by stripe.
(2) That information is valid
    i.  valid-and-solvent number, CVC, exp date
(3) Stripe has responded to the requested processing.

Handler functionality:
1. The handler loads our secret stripe api key, and
2. attempts to charge the User's cc (referenced by a unique stripe token), for
a subscription, to our "S4" plan at stripe.

3a. handles several possible exceptions generated by stripe.
3b. In the case of a confirmation from stripe that subscription succeeded,
i.e. 'the card was charged', the handler:
   I.  logs a successful subscription on the webserver fs
   II. invokes the full_signup service provide by the flappserver service

4. In all cases renders an appropriate webpage and returns it to the
twisted web-server for subsequent transmission to the User's browser.

Also included are incomplete unittests for the above functionality.
Define the flappservice "full_signup" stripe style

This module/process/service defines the interface
the automation flappserver provides to the
webserver.

Once the webserver has a successful subscription
acknowledged by stripe, it submits the relevant
information (via FlappCommand.run) to the process
defined in this module.

After creating and/or appending to several log files
some unique to each signup, some of which persist across
subscriptions, this function initiates the provisioning
process with a call to "activate_subscribed_service".
Functionality to provision and test an S4 service.

These changes are relatively small tweaks to the
extant provisioning process.
Add a utility to testing stripe bucket creation.

Tweak replace server to reflect new function name.
Remove command line secret leakage.