Add options arg to groupShapes method

[Taha-Hassan-Git]

This PR seeks to make it easier to disentangle shape selection logic from the grouping shapes logic. This is one of two approaches we could take to this problem.

Other PR is here: #3691

I think this is a better method because it doesn't require consumers of the library with their own custom actions to change the way their own grouping logic works. As evidenced by all the tests failing on the other PR.

Change Type

• sdk — Changes the tldraw SDK
• dotcom — Changes the tldraw.com web app
• docs — Changes to the documentation, examples, or templates.
• vs code — Changes to the vscode plugin
• internal — Does not affect user-facing stuff

• bugfix — Bug fix
• feature — New feature
• improvement — Improving existing features
• chore — Updating dependencies, other boring stuff
• galaxy brain — Architectural changes
• tests — Changes to any test code
• tools — Changes to infrastructure, CI, internal scripts, debugging tools, etc.
• dunno — I don't know

Test Plan

1. Add a step-by-step description of how to test your PR here.

• Unit Tests
• End to end tests

Release Notes

• Add a brief release note for your PR here.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
examples	✅ Ready (Inspect)	Visit Preview	May 3, 2024 11:40am

1 Ignored Deployment

Name	Status	Preview	Updated (UTC)
tldraw-docs	⬜️ Ignored (Inspect)		May 3, 2024 11:40am

[ds300]

I think it would be better to combine these into one options argument while preserving backwards compatibility. something like this

export type TLGroupShapesOptions = {
	selectAfterGrouping?: boolean
  shapeId?: string
}

// ...


groupShapes(shapes: TLShapeId[] | TLShape[], options: TLGroupShapesOptions | TLShapeId = {}) {
  if (typeof options === 'string') {
    options = { groupId: options }
  }

  // ...
}

That way we keep the 'options' a bit tidier.