Use `id` instead of `index`

It seems to me that the data referred to as `index` is not really an index. At least it's not the node index when building the merkle-tree. It's a bit confusing when the nodes are stored in a flat data structure (e.g., a list).

When building the merkle-tree, there is an inherent ordering which is the order in which each hash is computed (using this order requires the least amount of memory to build the merkle-tree):
1. first data block is received, its hash is computed (A)
1. second data block is received, its hash is computed (B)
1. hash of (AB) is computed (C)
1. third data block is received, hashes computed (D)
1. fourth data block is received, hashes computed (E)
1. hash of (DE) is computed (F)
1. hash of (CF) is computed (G)
...

The `index` for the above hashes in the flat-tree are the following:
- A: 0
- B: 2
- C: 1
- D: 4
- E: 6
- F: 5
- G: 3

Maybe there is a reason for using `index` to refer to these nodes, but I could not find one. So, if there is no specific reason for this name, I propose to use `id` or maybe `position` instead.

(Same issue in datrs: https://github.com/datrs/flat-tree/issues/30)

Start by reviewing the flat-tree API and locating where the node field is called `index`, then compare that usage with the ordering example in the issue. Confirm with maintainers whether `id` or `position` is intended; done means the chosen name is applied consistently without changing the tree mapping behavior.

Written by the indexing model from the issue text.