Vitaly

Если даные только для внутреннего пользования, то намного лучше создать структуру Data (имя можно менее общее) или две структуры, если данные нельзя скомпоновать по смыслу в одну структуру.
Ну и наследовать все классы от QMainWindow это не очень правильно. Т.к. по смыслу в большинстве случаев главное окно одно. Этот класс отличается от обычного QWidget наличием дополнителных компонентов, добавленых по умолчанию (тулбар, например).

Вам нужно использовать scoped enum из C++11, их, в числе прочего, можно форвардно объявлять. В этом случае перечисление можно из класса вынести.
Если нет возможности включить поддержку C++11, то придется явно инклудить.

Во-первых поставьте системную Qt (погуглилте как это в вашем линуксе сделать), для вас это будет намного проще, чем собрать Qt самостоятельно и сделать все то, что CLion написала вам в лог.
Во-вторых CMakeLists должен быть примерно таким (ну инклюды там свои пропишите и пр.):

cmake_minimum_required(VERSION 3.0.0 FATAL_ERROR)

project(Foo)

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${Qt5Widgets_EXECUTABLE_COMPILE_FLAGS} -std=c++1y")

set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTOUIC ON)
set(CMAKE_AUTORCC ON)
set(CMAKE_INCLUDE_CURRENT_DIR ON)

find_package(Qt5Widgets REQUIRED)

include_directories(${Qt5Widgets_INCLUDES})
add_executable(Foo main.cpp)
qt5_use_modules(Foo Widgets Core)

Но зачем вам страдать с CLion, которая под разработку на Qt вообще не заточена? Не лучше ли взять нормальную IDE вроде QtCreator и не страдать?

Как в билдере не будет ;) VCL уже давно умер, как и MFC, тут вы правы что перешли.
VS -- это всего лишь IDE, довольно убогая для плюсов без всяких там решарперов и плагинов. Т.ч. пишут не на VS, а в VS.
Для C++ вменяемый GUI (и не только) фреймвок -- это Qt. Вот его и надо изучать, если хотите интерфейсы (про QML не забудьте). Я бы сказал, что соотвествующих по уровню альтернатив просто нет. По рынку труда ситуация таже.
Кстати, для VS есть расширение для поддержки Qt. Я правда не уверен насчет расширений для самых последних версий (т.к. под виндами не работаю), но можете глянуть на сайте.

Как и в случае с обычной функцией:

template <class F>
void foo(F f) {}

Да.

std::shared_ptr<int> p(new int[42], std::default_delete<int[]>());

Как обращаться... Разыменовать и обращаться по индексу. Впорос только зачем.

У вас не такие уж и большие числа. Поищите тут нужный тип: en.cppreference.com/w/cpp/language/types
Если не подходит, то библиотеки вроде gmp.

На самом деле вам не нужно ничего и никуда передавать, как мне кажется. Т.к. вторая форма используется только для создания новых элементов. Но обо всём по порядку. В приведённом фрагменте кода я вижу несколько архитектурных проблем (если не интересно, можете игнорироваться все, кроме пункта 3):
1) Вторая форма создаётся каждый раз, когда пользователь кликает на кнопку add_item. Это утечка памяти, т.к. все формы будут удалены только после удаления главного окна, но не ранее. Почему бы не создать форму один раз и просто её не показывать на действие? Создали в классе поле QScopedPointer m_addItemDlg (ну или std::unique_ptr), один раз выделили память в конструкторе и радуетесь жизни.
2) Это не очень хорошо, что Institution хранится в контейнере QList по значению т.к., скорее всего вы не реализовали семантику перемещения и всё это копируется... Хотя бы по этой причине (и по многим другим) стоит подумать о том, чтобы хранить все элементы как shared_ptr.
3) Наконец-то мы добрались и до вашего вопроса! В Qt есть отличный механизм слотов и сигналов. В вашем случае идея проста: у главной формы надо реализовать слот onInstitutionAdded а у второй формы дописать сигнал institutionAdded и соединить их в конструкторе главной формы. Когда новый объект создан выслать сигнал из второй формы и в слоте главного окна реализовать добавление в коллецию.
Если же нужно будет редактировать какой-то итем в коллекции, то его конечно лучше передать просто по ссылке перед тем как показать форму. Ну и в этом случае посмотреть уже в сторону Qt model-view.
4) Название класса второй формы слишком общее и ни о чем не говорит.

Для сереализации в Qt есть специальный класс QDataStream. У классов которые вы хотите сереализовать нужно реализовать два оператора (для чтения и для записи):

QDataStream &operator<< (QDataStream &out, const T &obj);
QDataStream &operator>> (QDataStream &in, T &obj);

QFile f("path");
if (f.open(QIODevice::ReadOnly) { // or WriteOnly, or ReadWrite
   QDataStream s(&f);
   T obj;
   s >> obj; // for write s << obj
}

Но у вас в коллециях указатели, т.ч. сереализоваться будут адреса, а не сами объекты. Эту проблему нужно как-то решить, т.е. если у вас QList<Institution> lst, то можно просто написатьs << lstдля сереализации, а если указатель, то нет, возможно написать соотвествующий оператор для указателя -- это решение.

А еще возможно стоит присмотреться к JSON (с пятой версии поддержка входит в стандартную библиотеку Qt) если нужно именно сохранять в файлы, потом читать и иметь возможность поправить руками.

PS код писал просто по памяти, поэтому может не скомпилироваться :) Но примерно дела обстоят так.
PPS и лучше используйте какие-нибудь умные указатели вроде QSharedPointer, boost::shared_ptr или std::shared_ptr (с C++11)... Голые указатели уже моветон.

Это зависит от того, какие конкретно приложения вам нужно писать. Если это что-то под сенсорный дисплей, то выбор однозначен (QML), если под десктоп и это еще одна бухгалтерская программа, т.е. нет много 3D, работы с QGraphicsScene или OpenGL, то использовать QML будет приятнее чем классические виджеты -- писать проще и быстрее, но пока не освоитесь будете плеваться и хотеть бросить :)
А так-то посмотрите, например на hh.ru процент вакансий где требуется Qt и именно QML, думаю, что стандартные виджеты еще долго жить будут.