Error refactor

Зачем:

• чтобы со стороны клиента сервиса сразу в SDK видеть какие ошибки у метода возможны и их структуру
• чтобы удобно их обрабатывать на стороне клиента
• Чтобы найти в специфичной ошибке всю инфу о ней
• чтобы удобно выкидывать ошибку на стороне сервера
• что бы аналитик мог заводить ошибки в спецификации сам
• для возможности программной обработки ошибок сервисов

Поскольку ошибки специфичны для метода, то и ошибки специфичного класса Принципы реализации: В респонсах методов описываем Error специфичный для метода. в Error обязательно request_id, occurred_at серверрный timestamp и специфичный Reason - oneof набор вариантов ошибок, характерных для конкретного метода ошибки могут быть описаны

• в объекте (DTO), если специфичны для объекта
• в респонсе, если специфична для метода
• в общей Error, если она для нескольких методов в специфичной ошибке reason произвольный набор полей, специфичный для ошибки, или вовсе нет полей не должно быть полей ...Exception... - исключения остаются внутри реализации, а не в протоколе.

Убрал UnknownException. UnknownError внутри специфичной причины можно убрать, если она не возникает ни в каком языке UnknownError внутри специфичной причины можно оставить, в языках где она не возникает не обращать на нее внимание

• Поменял exception на error
• Убрал лишние описания ошибок, которые не использовались
• перенес SaveSubscriptionError в Subscription, поскольку нехорошо ссылаться из Subscription на SaveSubscriptionResponse. Объект не должен ничего знать про методы