Added conflict handling

[TheMrZZ]

Changelog:

• Fixed nested functions being overriden by parent functions when defined separately.
• Added conflict handling strategies.

Conflict strategies

Values

Conflict handling strategies define what Sandstone should do when two resources of the same type (MCFunctions, Advancements...) have the exact same name. All resources have the following available strategies:

• warn (default): Logs a warning to the console, and replace the previous resource with the new one.
• replace: Silently replaces the previous resource with the new one.
• ignore: Silently keeps the previous resource, discarding the new one.
• throw: Throws an error.

MCFunctions have two additional strategies:

• append: Appends the commands of the new MCFunction on the bottom of the new one.
• prepend: Prepends the commands of the new MCFunction on the top of the new one.

The default strategy for all resources is warn.

Changing the strategy

You can change the strategy:

• In the Sandstone configuration file, sandstone.config.ts. You can change the default strategy, and override this value on a per-resource-type basis:

  {
  onConflict: {
  default: '...', // Changes the default strategy
  advancement: '...', // Changes the default strategy for all Advancements,
  ...
  }
  }

• On a per-resource basis:

  
  MCFunction('name', () => { ... }, {
  onConflict: '...',
  })

Tag('name', ..., { onConflict: '...', })

Advancement('name', ..., { onConflict: '...', })

## 'append' and 'replace'

`append` and `replace` are uncommon strategies, but they can be very useful when used properly.
Let's say you want to summon entities with a specific UUID, and `/kill` them when uninstalling the data pack.

In the past, you would have done the following:
```ts
let uuids: string[] = []
MCFunction('first', () => {
  const uuid = generateUUID()
  uuids.push(uuid)
  summon('armor_stand', rel(0, 0, 0), { UUID: uuid })
})

MCFunction('second', () => {
  const uuid = generateUUID()
  uuids.push(uuid)
  summon('armor_stand', rel(0, 0, 0), { UUID: uuid })
})

MCFunction('uninstall', () => {
  for (const uuid of uuids) {
    kill(uuid)
  }
})

There is a big problem in this sample. If you put the definition of uninstall before first and second, the entities will never be killed, because the uninstall function will be created before first and second. This make function creation order-dependant, which can lead to unexpected bug.

With conflict strategies, we can refactor the previous snippet, and make it order-independant:

function killOnUninstall(const uuid: string) {
  MCFunction('uninstall', () => { 
    kill(uuid)
  }, { onConflict: 'append' })
}

MCFunction('first', () => {
  const uuid = generateUUID()
  killOnUninstall(uuid)
  summon('armor_stand', rel(0, 0, 0), { UUID: uuid })
})

MCFunction('second', () => {
  const uuid = generateUUID()
  killOnUninstall(uuid)
  summon('armor_stand', rel(0, 0, 0), { UUID: uuid })
})

Here, the order doesn't matter anymore. This behavior allows powerful patterns.