Generalize rules for "workflow" sigil

Summary:
See discussion in D6130. Basically, all of these should activate workflow:

  <a data-sigil="workflow" href="...">...</a>

  <div data-sigil="workflow">
    <a href="...">...</a>
  </div>

  <form data-sigil="workflow" action="...">...</form>

  <div data-sigil="workflow">
    <form action="...">...</form>
  </div>

The only case where we don't want to activate workflow is this one:

  <form data-sigil="workflow">
    <a href="...">...</a>
  </form>

Here, the form should workflow but the `<a />` should not.

These cases aren't really covered:

  // Undefined no matter where "workflow" is because it's nonsense.
  <a><a>...</a></a>

  // As above except like a million times more dumb.
  <form><form>...</form></form>

  // This one is ambiguous. The <a /> will currently workflow. We don't do
  // this anywhere and probably never will. If we want a different rule we
  // can cross that bridge when we come to it.
  <div data-sigil="workflow">
    <form action="...">
      <a href="...">...</a>
    </form>
  </div>

Test Plan: Clicked/submitted some things with workflow.

Reviewers: chad

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D6131
Remove all the container node stuff from AphrontTagView

Summary: See discussion in D6131, D6130. This turned into 35 layers of mess so throw it away and just tweak the JS to be more flexible.

Test Plan:
  - Clicked "Show More Applications".
  - Clicked "Show Fewer Applications".
  - Edited tasks using popup dialog.
  - Tried to drag tasks using pencil icon (correctly no longer works).
  - Changed threads in Conpherence.
  - Not sure how to actually hit the Conpherence "Load ... Threads" thing since
    it seems to auto-load? But that works, at least, and the code doesn't really
    care what you hit.
  - Added a conpherence participant.
  - Added a new calendar item.
  - Poked around other menus.

Reviewers: chad

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D6133
Allow named queries to be reordered by dragging

Summary:
Also you have to drop them. So drag, and then drop.

This needs some cleanup and reconciliation/generalization with the Maniphest implementation. In particular, you can't drag things to the very top right now, and they should share more CSS and more behaviors.

Test Plan:
Look I alphabetized them:

{F45286}

Reviewers: chad

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D6136
Restrict icon hover on lists to sidebar.

Summary: Needed to be more restrictive

Test Plan: Test maniphest and list examples.

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D6139
Simplify drag-and-drop list implementations

Summary:
  - Use the same styles for shared operations (`drag-ghost`, `drag-dragging`).
  - Move shared code into the base class.

Test Plan: Dragged around tasks and named queries.

Reviewers: chad

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D6141
Default application search to the topmost filter

Summary: Allow users to set a default by dragging it to the top. When they land on a page without a saved query, choose their default.

Test Plan: Hit `/paste/`, got my default results, etc.

Reviewers: chad

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D6140
Lots of Icons

Summary: Tweaks the dark, grey, and white icons to match the action-icons. Also added a home icon for navigation.

Test Plan: looked at list navs, action menus.

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D6142
Add home icon to examples

Summary: home icon on examples

Test Plan: O.O

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D6145
Make some incremental improvements in Diviner

Summary: Gets TOC populated for articles, at least, and fixes a few other things.

Test Plan: {F45474}

Reviewers: chad

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D6144
Fix Diviner issue when publishing new atoms

Summary: We need to make sure the symbol is always saved before the atom. I mucked this up recently and didn't catch it locally since I'd already generated the atoms.

Test Plan: Ran `bin/diviner generate` after truncating all diviner tables.

Reviewers: chad

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D6146
PHUIList changes for responsive design

Summary: Fixes some issues with lists and tablet/mobile layouts.

Test Plan: shrink my screen

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D6148
PHUIDocument view for mobile devices.

Summary: Adds collapsing of the sidebar, also allows you to say where it goes on mobile (above or below content). ToC for example, above. General Navbar, below. Up to you.

Test Plan: Review UIExamples and Diviner.

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D6150
Begin generalizing custom fields

Summary:
Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit.

For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though:

  - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch.
  - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed.
  - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field.

For ApplicationSearch, I've adopted and generalized D5278.

For ApplicationTransactions, I haven't made any specific affordances yet.

For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this:

  - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled.
  - We load every avialable field to populate this list. New fields will appear at the bottom.
  - There are two downsides to this approach:
    - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream.
    - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability.
    - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to.
    - We can fix both of these problems with a straightforward configuration migration if we want to bother.
  - There are numerous upsides to this approach:
    - We can delete a bunch of code and replace it with simple configuration.
    - In general, we don't need the "selector" classes anymore.
    - Users can enable available-but-disabled fields with one click.
    - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff.
    - Generally, it's super easy for users to understand.

This doesn't actually do anything yet and will probably see some adjustments before anything starts running it.

Test Plan: Static checks only, this code isn't reachable yet.

Reviewers: chad, seporaitis

Reviewed By: chad

CC: aran

Maniphest Tasks: T1703

Differential Revision: https://secure.phabricator.com/D6147
Flesh out ApplicationTransactions/CustomField integration

Summary:
None of this code is reachable yet. See discussion in D6147. Ref T1703.

Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation.

Test Plan: Code not reachable.

Reviewers: chad, seporaitis

Reviewed By: chad

CC: aran

Maniphest Tasks: T1703

Differential Revision: https://secure.phabricator.com/D6149
Remove subscribe icons

Summary: Used more logical icons for subscribe, auto, and delete instead of the mail icons. Fixes T3329

Test Plan: Tested subscribing and unsubscribing in Maniphest.

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T3329

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