`tovector` does not mandate closing `">"`

[tapple]

There's an inconsistency here:

> tovector("<2, 3, 3")
<2, 3, 3>
> lljson.sldecode('"!v<2, 3, 3"')
stdin:1: malformed tagged vector: !v<2, 3, 3
stack backtrace:
[C] function sldecode
stdin:1

However, I'm hesitant to fix this (by making tovector return nil). I feel like maybe tovector should stay a little more lenient than !v, since it's for reading typo-prone notecards

tovector is consistent with (vector) on this point:

llOwnerSay((string)((vector)"<2, 3, 3")); // <2,3,3>

But it's stricter on other points:

> tovector("<2, 3, 3,xx>e1")
nil

llOwnerSay((string)((vector)"<2, 3, 3,xx>e1>")); // <2,3,3>

Originally posted by @tapple in #61 (comment)

[monty-linden]

@joosten this is probably fixed at this point. Want to verify with you...

[HaroldCindy]

It is not, tovector() still behaves this way, haven't decided what to do just yet

[tapple]

Let me know if you want me to post a canny

[tapple]

I wouldn't mind if the opening < was also optional. In the two places I use this (parsing notecards, parsing chat), it's already expected to be a vector from context.
This would be consistent with sldecode:

lljson.sldecode('"!v1, 2, 3"') -- <1, 2, 3>

But inconsistent with (vector):

llOwnerSay((string)((vector)"2, 3, 3")); // <0,0,0>

[HaroldCindy]

@tapple You don't need to make a Canny for this, github is best for things if you know for a fact that it's related to something in this repo specifically.

Canny makes the most sense for server bugs, they largely just get copied to an internal server repo's github issues that you would be able to create yourself.

[tapple]

canny is also slightly better at getting eyeballs, feedback, and arguments. Which is the reason I suggested it in this case