odd newline & indentation choices about verusfmt

[parno]

We have an exception for #[trigger], but otherwise, attributes always go on their own line; we could consider adding #![all_triggers] to that exception list. The indentation of the && P is expected, since we filled up the previous line, and the formatter is allowed to break lines before binary operators like &&, which it then indents. The architecture of verusfmt doesn't allow prioritizing line breaks, so we can't say that we might prefer it to break after, say, the implication. The line breaks before the arguments to op are also expected, once you need to break up a function call. The one oddity is that we might hope for those arguments to be indented one more time relative to the previous line. There's probably some unfortunate interaction between the various levels of nested indents, but I think this falls into the category of "pull request welcome".