Trigger customization notifications on ide, stacking multiple notifications vertically and refactor/add support for more methods in PluginStore

[pras0131]

Reference ticket: https://issues.amazon.com/issues/ECLIPSE-297

• Trigger IDE notifications on customization updates or selection of default foundation.
• The PR also includes changes to stack multiple notifications vertically and the logic to reposition notifications once any of the notification is closed. The CRUX of the implementation is AbstractNotificationPopup initializeBounds() method, which has been overriden according to our requirements and repositioning of notifications once the older ones starts to flash out.
• Support for two new methods - putObject and getObject in the PluginStore to ease set/get for more complex objects other than just plain strings.
• Refactored the customizations preference storage code to let it store the entire customization object, rather than storing each of the individual fields.

[breedloj]

Can we not just store the ARN?

[pras0131]

Earlier I was just storing ARN only but I need to have name (or maybe description as well later) for showing notifications. So instead of creating 3 different getter/setter for all of these, I changed the implementation to just have a single setter/getter.

[breedloj]

Having a synchronized block here adds no value since the underlying call to add is thread safe since you're using a CopyOnWriteArrayList. It would make sense if you are trying to perform several operations together in an atomic unit of work.

[pras0131]

makes sense, I can actually remove the synchronized block. Thanks for this.

[breedloj]

While this technically can be done serializing entire objects does present additional risks. In general I would like to be convinced that use cases require it, vs. binding relational configuration under a common key namespace, e.g.:

notifications.foo: 123
notifications.bar: 456

[pras0131]

For the same reason which I described here https://github.com/aws/amazon-q-eclipse/pull/48/files#r1787324480

Also, currently when LSP server requests for aws.q, we only return customization object but maybe in near future - we might be returning more than just one single row item. Then in those kindof cases, it would be better to just do a single lookup and return it.