Take options object as alternative to private/public keys

[stuartpb]

Also, ditch the current other two parameters: data should be an argument to verify (not the constructor, WTF), and the secure boolean is basically a huge mistake.

Options:

• protocol: The protocol that will be used for all requests. Defaults to 'https://'. Can be '//', in which case validation requests will be made over HTTPS and inclusions for the widget will be protocol-relative.
• RecaptchaOptions: If present, the widget/toHTML output will be prefixed with a <script> that shadows any existing RecaptchaOptions with the values from this.
• customWidgetId: Equivalent to / overrides RecaptchaOptions.custom_theme_widget.
• customWidgetHTML: Custom theme widget HTML. If present, the RecaptchaOptions shadowing <script> will be added, with a default value of "recaptcha_widget" for RecaptchaOptions.custom_theme_widget (if not specified via RecaptchaOptions). The content of customWidget will be prepended to the widget/toHTML output, in a div with the id that RecaptchaOptions.custom_theme_widget is set to.

These keys will also be shadowed into RecaptchaOptions:

• lang
• theme
• custom_translations or customTranslations
• custom_theme_widget or customThemeWidget (will also be overridden by customWidgetId)
• tabindex

Also, note that I would generally consider RecaptchaOptions to be a presentation detail that should be handled in the template- all these options in the constructor are just an alternative. (You don't even need to use .widget/.toHTML at all.)

[stuartpb]

Maybe all these widget options should be available as an option to .widget()/.toHTML() (while still allowing their defaults to be specified).