Attach and unattach code must be reviewed (attachTo, unattach, addAttachment, removeAttachment)

There are two places to store attach info (both used by cards/effects):
- inside attaching permanent: `attachedTo`;
- inside permanent with attachments list: `attachments`

1.
That fields must be synced but there are possible problems with data consistence in some use cases in theory. As example: attachment can lost `attachedTo` information on restricted `removeAttachment`:

`removeAttachment` example with too early `attachedTo` clean up:

It's not lead to any bugs cause there aren't any effects that can replace/restrict `UNATTACH` events but it can be affected in the future.

2.
`addAttachment` use `attachTo`-`removeAttachment` code but it ignore bad `removeAttachment` result (same problem as number 1 above).

3.
Also usage of attach and attachment methods must be splits between game engine and cards. Attach/unattach for game engine usage only, addAttachment/removeAttachment for cards/effects.

Start by locating attachTo, unattach, addAttachment, and removeAttachment, then trace their use by the game engine and by cards/effects. Review how attachedTo and attachments are updated, including restricted removeAttachment results; done means the storage stays consistent and the engine/card method responsibilities are clearly separated.

Written by the indexing model from the issue text.