Allow JIRA auth adapter to export a "JIRA Future"

Summary: Ref T3687. Cleans up the API a bit so we can make JIRA calls more easily.

Test Plan: See next revision. Logged in and out with JIRA.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3687

Differential Revision: https://secure.phabricator.com/D6877
Fix literal block

Summary:
Also try to consolidate lines parser code for literal and code
blocks by adding an intermediate ##PhutilRemarkupEngineMultiLineEnclosedBlockRule##
class.

Test Plan: Tested literal and code blocks in sandbox.

Reviewers: epriestley

Reviewed By: epriestley

CC: ldbrandy, Korvin, aran, wez

Differential Revision: https://secure.phabricator.com/D6848
Provide explicit remarkup block priorities

Summary:
D6848 fixed some issues with the `%%%` literal block syntax, but this had a side effect of breaking list syntax //if// the blocks were added in a different order than libphutil adds them. It also created an order-dependent issue with the space-only rules in the code block.

To fix this:

  - Add explicit block priorities so the order they're declared in doesn't matter. We did this for inline rules some time ago, and it seems to work well.
  - Explicitly break the input order of blocks to force the priority rules to take effect during unit tests.
  - Split the code and literal blocks apart again, so the space-only logic doesn't run in the literal block. The complexity to keep them inheriting a common parent while separating this logic out didn't seem worthwhile.

Test Plan: The unit tests from D6848 still pass.

Reviewers: andrewjcg, btrahan, chad

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D6889
Add an option to HTTPSFuture to ignore Location headers

Summary: Sometimes it can be handy to get the request directly rather than following a redirect, such as a badly-implemented 404 page or a broken webserver sending data alongside a Location header.

Test Plan: Use HTTPSFuture to download data from one of said broken servers.

Reviewers: epriestley

Reviewed By: epriestley

CC: Korvin, aran

Differential Revision: https://secure.phabricator.com/D6897
Encode/sign JIRA POST requests like JIRA expects

Summary: Ref T3687. Currently we use generic OAuth1 rules here, but JIRA expects bodies to be JSON encoded and not included as part of the signature. Left a comment about this in case we need some other behavior in general, but this is probably the simplest thing that could possibly work for now.

Test Plan: Performed API POST requests to JIRA, got action on the other side.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3687

Differential Revision: https://secure.phabricator.com/D6891