fix: Differentiate between an object that has a literal * field, and a pointer to an object's additionalProperties shape.

[jshearer]

This flake was caught by quickcheck (only sometimes) and was causing Flow CI to intermittently fail.

The one thing I'm not confident on is calling this variant AdditionalProperties, since the variant for array's additionalItems is called Token::NextIndex, not Token::AdditionalItems. Thoughts @jgraettinger?

---

This change is 

[jgraettinger]

Looks good, some detail comments on specific case handling, and i think we should use NextProperty for the variant.

[jshearer]

Ok @jgraettinger I think this is ready to be looked at again. Changing Token::from_str and adjacent logic to no longer parse - broke a couple tests which I updated to match the new logic, but anything else that depended on that functionality will be broken.. I think the tests should have caught most of those? I also did run a quick e2e test of starting up a local stack, publishing ops catalogs, running a hello-world capture, etc. which all appeared to work

[jgraettinger]

LGTM % some minor nits and adding a bit of removed test coverage back

[jgraettinger]

add back the /foo/- case here by manually building up the tokens? You can't implicitly build them by parsing a pointer as it used to do, but you can still build it manually.

Also add a case covering creation with NextProperty. It'd return None, right?

[jshearer]

Got totally side-tracked and forgot to finished this. What do you mean by adding /foo/- back? That pointer wouldn't make any sense even if I did create it by hand: /foo is an array, and - is interpreted as an object field called -, which you can't use to index into an array array.

Also add a case covering creation with NextProperty. It'd return None, right?

Done

[jgraettinger]

I meant build it up from tokens, rather than parsing, so that it's the NextIndex variant.

It's possible to build such a pointer and pass it to create, right? Let's cover that in the test.

[jgraettinger]

still lgtm!