Add warning for lvalue indexing inconsistency.

[nhuurre]

Submission Checklist

• Run unit tests
• Documentation
  • If a user-facing facing change was made, the documentation PR is here: Document lvalue multi-indexing deprecation docs#464
  • OR, no user-facing changes were made

Fix #531.
Typechecker would check LValues as if they were RValues but codegen just flattens nested indexing. If these interpretations implied different type for the LValue then stanc3 would generate invalid C++ code. This case in now a type error.
For backwards compatibility, if the generated C++ code would have compiled before then the typechecker only emits a warning.

Single indexing may be arbitrarily nested as long as only the outermost index group contains multi-indexes (these cannot cause ambiguity)

x[1,2][3][4] = ... // ok
x[1, 2][:,4] = ... // ok
x[1, :][3,4] = ... // bad

Release notes

Deprecate nested multi-indexing on lvalues as it is inconsistent with rvalues.

Copyright and Licensing

Copyright holder: Niko Huurre

By submitting this pull request, the copyright holder is agreeing to
license the submitted work under the BSD 3-clause license (https://opensource.org/licenses/BSD-3-Clause)

[WardBrian]

More of a question than anything - after removal do you think we should change the parser/AST to enforce this, or keep it in typechecking?

Is the eventual hope to re-introduce with matching semantics?

[nhuurre]

I don't know. Cleaning up the AST seems like a good idea but nested indexing is still allowed when all the indexes are simple integers. If we change the AST then pretty printer will always flatten the indexes. That may be acceptable, it's not like pretty printer preserves all the formatting anyway.
In my opinion nested indexing is just an accidental consequence of the ability to index any expression. It's not necessary to support it in lvalue position, where arbitrary expressions aren't allowed.

[WardBrian]

Fair enough. Does this change do anything for nested indexing on the left hand side of a ~, or is that technically fine since it ends up inside a lpdf? I'm fuzzy on whether that counts as an l-value or not.

[nhuurre]

No change there, the "left-hand side" of a tilde statement is not an lvalue.

[WardBrian]

Looks good