Alex

Ну вы же понимаете, что там абсолютно другой стек технологий, которым вы будете достаточно жестко ограничены? Очень многое зависит от ваших планов на будущее - всё же шарп и в чуть меньшей степени java это явный корпоративный уровень, следовательно и задачи соответственные - имхо никаких тебе стартапов и прочей веселухи.
Чтобы читать литературу необязательно досканально знать синтаксис языка в примерах.
Ну и не совсем понятна связь перехода с php7.

Отдельные таблицы для каждого типа уведомления не рассматриваются?
Сущности у вас же будут разные, какой тип для resource_id вы выберете? Bigint надо брать :)
Можно иметь общую таблицу уведомлений (notifications) для удобства выборки, в которой будет помимо прочего пара полей FK (notification_type + notification_id) и на каждый тип своя таблица (comment_notifications, like_notifications) с любыми наборами полей, необходимыми для каждого типа.
Ну это так, первые мысли вслух.

Например так: symfony.com/doc/master/book/forms.html#validation-... Новый метод configureOptions, начиная с 2.7
Но пока можно использовать старый вариант, если не раздражают перечеркнутые слова в том же шторме

Элегантно переопределить блок form_start :)

Потому что assetic
+ www.whitewashing.de/2013/08/19/speedup_symfony2_on...

Можно глянуть на ExpressionLanguage, но имхо лучше заполнять select в билдере формы

В чем проблема добавить еще одно поле с типом (для какого действия)?
На каждое действие лучше отдельный токен.
Поле value вообще ни о чем: для одних действий избыточно, для других недостаточно. Возможно есть смысл иметь общую таблицу без value + отдельные таблицы токенов под конкретные задачи, где нужны доп. поля