[1/n][sl][github][gh stacks] support headers and list params

[raydatray]

ctx

github added native stacked pull requests, it would be nice to add native support to it for sapling!

this stack lets sl pr submit and sl pull via a new github.pr.workflow = stacked mode

changes made

• github_gh_cli.make_request accepts custom headers (-H, needed for the X-GitHub-Api-Version preview header)
• _format_param supports list values using the gh api repeated-field syntax (pull_requests[]=101)
• mock_utils updated to match

test plan

doctests in _format_param (registered in test-doctest.py), existing github .t suite

---

Stack created with Sapling. Best reviewed with ReviewStack.

• [7/7][sl][github][gh stacks] update some documentation #1398
• [6/n][sl][github][gh stacks] wire up gh stacks to sl pull #1397
• [5/n][sl][github][gh stacks] wire up gh stacks to sl pr submit #1396
• [4/n][sl][github][gh stacks] update submit body for stacks #1395
• [3/n][sl][github][gh stacks] add stacked workflow for submit #1394
• [2/n][sl][github][gh stacks] add support for stack endpoint #1393
• -> [1/n][sl][github][gh stacks] support headers and list params #1392

[meta-codesync]

This pull request has been imported. If you are a Meta employee, you can view this in D114402510. (Because this pull request was imported automatically, there will not be any future comments.)

[genevievehelsel]

Suggested change

	if isinstance(value, list):
	return list(
	itertools.chain(*[_format_param(f"{key}[]", v) for v in value])
	)
	if isinstance(value, list):
	if not value:
	return ["-F", f"{key}[]"]
	return list(
	itertools.chain(*[_format_param(f"{key}[]", v) for v in value])
	)

I have not finished reading the stack, but gh api states "To pass an empty array, use key[] without a value." (https://cli.github.com/manual/gh_api)

if we're formatting a empty list, we should do so explicitly rather than dropping the param and not sending it since it seems like "empty array" and "missing field" can have different behaviors downstream

[lazopm]

I am really excited for this to land! after leaving Meta having diff stacks is something I miss every day. If we get this right it might be the thing that pushes SL more mainstream. Today it's hard for me to sell sapling to my team since the workflow generates unreadable massive PRs unless you're diligent about managing the stack, and using ReviewStack on top just feels hacky vs something native to github.

@raydatray any chance you could upload a screencast of the workflow in your test plan? In fact, can we make THIS stack use the github stacked PRs feature?

I hope we can expedite merging this behind an experimental setting flag. @genevievehelsel @raydatray

I'm writing a ton of PRs across 2-3 repos with sapling, happy to beta test and file/fix bugs as I find them.