Adapter Ids: where to store them?

We have 3 options so far.

### 1) CustomData
As we do now. `Dictionary`.

Pro:
- It's what we have, no changes needed
- They are stored in a Dictionary, which is a base C# type
- Easy to manage

Cons:
- Arguably CustomData should be left for *custom* data, not data that is mandatory to have in order for some base BHoM functionality to be working (like the Push). So it's not the *proper* place for the AdapterId.

### 2) A Fragment.
Pros:
- In a certain way, it's more appropriate than CustomData. We do use fragments to specify data that may or may not be required on objects.

Cons:
In a certain way, the AdapterId is not that appropriate as a fragment.
- We would need to explain the concept of Fragments to every single person coming to implement a new toolkit, even if the only thing they need to do is add an `int` to an object. This makes Fragment sound inconvenient.
- If we want to avoid that, we might have an `AdaptersIdFragment` that actually stores a Dictionary of values, like the CustomData:
```cs
public class AdaptersIdFragment : IBHoMFragment
{
public Dictionary AdaptersId { get; set; }
}
```
This comes with a drawback. If you want to add a new Id to the object, you need to:
- check whether it already has an `AdaptersIdFragment`
- if it has, store the value contained in its dictionary
- add or replace the id in the dictionary
- replace the dictionary contained in the `AdaptersFragment`.
- use `bhomObject.AddFragment(adaptersFragment, true)` to replace the fragment.
Since this involves a retrieve operation and quite few steps, it might be a performance hit. Also, it requires a few helper methods.

We could solve this with an utility method "modifyFragment" to modify the Dictionary stored there. But I'm not sure this is how we want Fragments to be.

All this to say I'm not sure I find it appropriate as a replacement of the CustomData.
This is essentially because Fragments are not supposed to be used this way: I think that **fragments do not work well with collections of values which are supposed to shrink or expand**, like the AdapterId.

### 3) An additional property of `IBHoMObject`.
Pros:
- Easy to implement
- Arguably, any IBHoMObject can be pushed, so it could make sense to have a property dedicated to its AdapterId

Cons:
- Not all Adapters need to have the concept of an Adapter_Id.

@al-fisher @rwemay @IsakNaslundBh @adecler @epignatelli

Start with the issue's three proposed storage options: CustomData, a fragment, or an additional IBHoMObject property. Review the existing AdapterId, CustomData, IBHoMFragment, and IBHoMObject concepts referenced in the discussion, then resolve the trade-offs with maintainers. Done means reaching and documenting a decision; the issue names no files or tests.

Written by the indexing model from the issue text.