Flatten Object List items and lighten up grey buttons

Summary: Moving towards a flatter, crisper layout with some minor tweaks here. The button styles and object item styles now have consistent colors and depth. Will continue to repeat this pattern and build out a standard 'grey' palette.

Test Plan: Test homepage and maniphest home.

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: Korvin, aran

Differential Revision: https://secure.phabricator.com/D6828
Update pinboard view

Summary: Updates the pinboard layout with less shadow and more standard border colors.

Test Plan: Reload pinboard

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: Korvin, aran

Differential Revision: https://secure.phabricator.com/D6829
Generate some amount of PHP class documentation

Summary:
Ref T988. This brings the class/interface atomizer over. A lot of parts of this are still varying degrees of very-rough, but most of the data ends up in approximatley the right place.

ALSO: PROGRESS BARS

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T988

Differential Revision: https://secure.phabricator.com/D6817
Add source links and a little documentation about Diviner

Summary: Ref T988. Links up the "Declared:" property to point at a repository browser, if one exists.

Test Plan: Viewed a class document, saw a link, clicked it, got the definition.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T988

Differential Revision: https://secure.phabricator.com/D6820
Standardize rendering of atom type names like "Article" and "Class"

Summary: Ref T988. This was sort of hard-coded in one place and not done properly in another. Do it consistently.

Test Plan: Looked at atom list; looked at atom view. Saw "Article", "Class" rendered correctly.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T988

Differential Revision: https://secure.phabricator.com/D6821
Reorganize Diviner articles into `user/` and `tech/`

Summary: Ref T988. I'm splitting the Phabricator documentation into two separate documentation books, one less technical and one more technical. Move all the `.diviner` article files around into `src/docs/user/` or `src/docs/tech/`, accordingly. The only actual changes here are a couple of config changes in the `.book` files.

Test Plan: Regenerated user and technical documentation and saw stuff in the right places.

Reviewers: btrahan

Reviewed By: btrahan

CC: chad, aran

Maniphest Tasks: T988

Differential Revision: https://secure.phabricator.com/D6822
Move child loading into DivinerAtomQuery and collect/organize more data on class Atoms

Summary:
Ref T988. This is //extremely// rough looking in the UI, but gets most of the information we need into the right places.

The controller rendering code is super rough too, I'm going to break that up shortly.

  - Add `needChildren()` to `DivinerAtomQuery`.
  - Compose and organize class methods when rendering classes. The old Diviner was not smart enough to do this, so a class would only document methods which the class itself implemented, not methods inherited from parents. I'd like to show those too to provide a more complete understanding of how to use a class (but they'll be marked with "inherited" or somesuch). This code walks the "extends" list and builds all of the class methods, annotating them with where they are defined and where they are implemented.
  - Coompose and organize "tasks". The old Diviner was not smart enough to do this, but I want to reduce the amount of duplicate/busy work involved in documenting subclasses. In particular, I want them to inherit "@task" declarations from parents so that class trees are more cohesive. They now do so.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T988

Differential Revision: https://secure.phabricator.com/D6823
Update PHUIDocument to use new header gradients

Summary: Adds the new gradient to document views

Test Plan: Tested multiple pages in my sandbox in Phriction, UIExamples.

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: Korvin, aran

Differential Revision: https://secure.phabricator.com/D6827
Restore fields to Releeph from prior to CustomField patch

Summary: See notes / inlines.

Test Plan: See inlines.

Reviewers: wez, btrahan

Reviewed By: btrahan

CC: btrahan, aran

Differential Revision: https://secure.phabricator.com/D6831
fix perf regression when using 'owned' query

Summary:
D6335 has some unexpected side effects.  This adds back the
where clause for the owned query.  There may be other problems.

Test Plan:
Ran:

```
echo '{"query":"owned","guids":["myphid"]}' | arc --conduit-uri=https://myhost call-conduit differential.find
```

Reviewers: epriestley, dschleimer

Reviewed By: epriestley

CC: Korvin, aran

Differential Revision: https://secure.phabricator.com/D6832
Allow disabled users to be typeaheaded in Differential

Summary: Fixes T3773. By default, the `/users/` datasource excludes disabled users (since it doesn't make sense to assign them tasks or make them reviewers, for example). However, for ApplicationSearch it does make sense to look for objects, e.g., authored by a disabled user.

Test Plan: Searched for disabled users in Differential.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3773

Differential Revision: https://secure.phabricator.com/D6834
Color time icons

Summary: Color time icons

Test Plan: Photoshop

Reviewers: epriestley

Reviewed By: epriestley

CC: Korvin, aran

Differential Revision: https://secure.phabricator.com/D6836
Hack-patch for missing highlights in Audit

Summary: When I swapped the views, I accidentally removed some controller -> view -> controller logic which is used to figure out which packages are highlighted. This code is a mess, but fix the feature for now and we can clean it up later.

Test Plan: {F56335}

Reviewers: wez, btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D6835
Add setEpoch() and onboard staleness to ObjectItemListView

Summary: Fixes T3486. I don't love how this looks -- maybe we could try different icons? Like white icons on a brighter red/yellow background?

Test Plan: {F56299}

Reviewers: chad, btrahan

Reviewed By: chad

CC: aran

Maniphest Tasks: T3486

Differential Revision: https://secure.phabricator.com/D6833
add committer as supported field for herald rules

Summary: Allows building Herald rules against committer, similar to author. Useful for monitoring cherry-picked commits.

Test Plan: Applied patch, restarted php-fpm and phd daemons to ensure code changes took effect. Added a new herald rule to trigger audit when committer was me. Cherry-picked someone else's commit (author=them, committer=me) and pushed to origin. Audit was triggered.

Reviewers: epriestley

Reviewed By: epriestley

CC: Korvin, aran

Differential Revision: https://secure.phabricator.com/D6838
Use bar colors to show revision status in revision lists

Summary:
Ref T3772. The original version of D5451 had a very colorful version of this which felt a bit arbitrary, and we moved away from it after discussion, particularly [[ https://secure.phabricator.com/D5451#comment-8 | here (chad) ]] and [[ https://secure.phabricator.com/D5451#comment-14 | here (me) ]] and [[ https://secure.phabricator.com/D5451#comment-19 | here (chad again) ]].

The core of my objection was that status and priority to the viewer aren't the same: a "needs revision" revision that you authored is high priority (you need to revise it), but a "needs revision" revision that someone else authored is low priority (you're waiting on them to revise it). If we color by status, revisions in both high priority and low priority states will be colored red. We can instead color by viewer priority (blocking others = red, needs attention = orange, waiting on others = blue; or something), but that would be redundant (we already group by it, so you'd get big chunks of stuff with the same color and color would have no utility), confusing (in ungrouped views, the colors would not be self-explanatory) and weirdly inconsistent (different users would see objects having different colors).

I still think all this holds, but I also thought that "viewer priority" was enormously more important than "state", since I use the former frequently and the latter very rarely. From T3772, it sounds like some users use "state" a lot more than I do (i.e., they want to find "accepted" revisions within a "viewer priority" group like "Action Required"). This is a possible approach to that.

I think another issue was the heavy use of the color in the original; this restores a more conservative version of it which doesn't have as much weight. In particular:

  - Revisions in the "Needs Review" state retain the default color, rather than orange.
  - Revisions in the "Closed" state have the disabled effect.

Test Plan: See screenshot.

Reviewers: chad, btrahan

Reviewed By: chad

CC: aran

Maniphest Tasks: T3772

Differential Revision: https://secure.phabricator.com/D6839
Allow construction of ApplicationSearch queries with GET

Summary:
Ref T3775 (discussion here). Ref T2625.

T3775 presents two problems:

  # Existing tools which linked to `/differential/active/epriestley/` (that is, put a username in the URL) can't generate search links now.
  # Humans can't edit the URL anymore, either.

I think (1) is an actual issue, and this fixes it. I think (2) is pretty fluff, and this doesn't really try to fix it, although it probably improves it.

The fix for (1) is:

  - Provide a helper to read a parameter containing either a list of user PHIDs or a list of usernames, so `/?users[]=PHID-USER-xyz` (from a tokenizer) and `/?users=alincoln,htaft` (from an external program) are equivalent inputs.
  - Rename all the form parameters to be more digestable (`authorPHIDs` -> `authors`). Almost all of them were in this form already anyway. This just gives us `?users=alincoln` instead of `userPHIDs=alincoln`.
  - Inside ApplicationSearch, if a request has no query associated with it but does have query parameters, build a query from the request instead of issuing the user's default query. Basically, this means that `/differential/` runs the default query, while `/differential/?users=x` runs a custom query.

Test Plan: {F56612}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2625, T3775

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