Accommodate multi-digit list markers

[jazairi]

Why these changes are being introduced:

The result list does not have a sufficient left margin to
accommodate list markers that are more than one digit. Because
of this, markers for results further down in the list are
truncated.

This issue exists on smaller viewports only. Larger viewports
have enough space for markers up to five digits. (This is the
maximum, in our case.)

Relevant ticket(s):

• GDT-314

How this addresses that need:

This adds a left margin on smaller viewports to accommodate
4-digit result markers, and removes the result padding to provide
more room for text flow.

Side effects of this change:

• The margin is somewhat excessive for 1- or 2-digit numbers, but
  it seems like a reasonable tradeoff for now.
• The leading digit of 5-digit numbers is still truncated. This only
  affects one possible result, and it's unlikely that a user would get
  to result 10,000.

Developer

Accessibility

• ANDI or WAVE has been run in accordance to our guide.
• This PR contains no changes to the view layer.
• New issues flagged by ANDI or WAVE have been resolved.
• New issues flagged by ANDI or WAVE have been ticketed (link in the Pull Request details above).
• No new accessibility issues have been flagged.

New ENV

• All new ENV is documented in README.
• All new ENV has been added to Heroku Pipeline, Staging and Prod.
• ENV has not changed.

Approval beyond code review

• UXWS/stakeholder approval has been confirmed.
• UXWS/stakeholder review will be completed retroactively.
• UXWS/stakeholder review is not needed.

Additional context needed to review

Try a broad search (I use 'data') and confirm that you can see all five digits of result marker 10000 on page 500.

Code Reviewer

Code

• I have confirmed that the code works as intended.
• Any CodeClimate issues have been fixed or confirmed as
  added technical debt.

Documentation

• The commit message is clear and follows our guidelines
  (not just this pull request message).
• The documentation has been updated or is unnecessary.
• New dependencies are appropriate or there were no changes.

Testing

• There are appropriate tests covering any new functionality.
• No additional test coverage is required.

[coveralls]

Pull Request Test Coverage Report for Build 9276206751

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 98.653%

---

Totals
Change from base Build 9227866449:	0.0%
Covered Lines:	586
Relevant Lines:	594

---

💛 - Coveralls

[JPrevost]

I wonder if this is why we had the results list numbers originally having a rule like we see removed here:
f278bb3

I'm not suggesting we change, I was just curious on the history of this type of iteration and it was interesting when I looked to see that this "bug" came out of an intentional change that didn't have the bug. Interesting.

[jazairi]

I wonder if this is why we had the results list numbers originally having a rule like we see removed here: f278bb3

Which rule are you referring to? If it's this one, the reason we removed it is because it looks weird. It does solve this particular problem, though.