Conflicting opinions between `air` and `lintr` for multi-line assign expressions

Unsure whether compatibility with lintr's formatting opinions is a design goal. If it isn't, feel free to ignore this!

When doing multiple assignments, as with the following code

a_really_long_symbol_name_that_requires_its_own_line <-
  a_really_long_symbol_name_that_requires_its_own_line_2 <-
  a_really_long_symbol_name_that_requires_its_own_line_3 <- "hello, world"

air will format it like this

a_really_long_symbol_name_that_requires_its_own_line <-
  a_really_long_symbol_name_that_requires_its_own_line_2 <-
    a_really_long_symbol_name_that_requires_its_own_line_3 <- "hello, world"

while lintr wants it to look like this (note the indentation)

a_really_long_symbol_name_that_requires_its_own_line <-
  a_really_long_symbol_name_that_requires_its_own_line_2 <-
  a_really_long_symbol_name_that_requires_its_own_line_3 <- "hello, world"

I used a simple example to illustrate the issue with just long symbol names, which is a pretty obscure use case. I've seen this in more practical examples when declaring multiple S7 methods from the same function definition.

There's some precedence for this operator indentation, given how the |> is often used in dplyr chains.

No file or test is named. Reproduce the multi-line assignment example in air and compare its indentation with lintr's output, then review the formatter's assignment and operator-indentation entry points. Done means deciding whether lintr compatibility is a goal and, if so, adding regression coverage for the chosen formatting.