Add deinit function for rpmsg tty transport.

[Hadatko]

This function adds deinit function for RPMSG LITE TTY transport. @MichalPrincNXP could you provide feedback please. Is it ok to deinitialize master/remote tty RPMSG instance like this?

[MichalPrincNXP]

@Hadatko, the order of deinitialization is not correct. It should be done in this order:
rpmsg_lite_destroy_ept(s_rpmsg, m_rpmsg_ept);
rpmsg_queue_destroy(s_rpmsg, m_rpmsg_queue);
rpmsg_lite_deinit(s_rpmsg);
RL_SUCCESS return value should be checked and if not returned the kErpcStatus_DeinitFailed (newly introduced in your PR) should be used

[Hadatko]

What should be done when deinit failed in destructor?

[MichalPrincNXP]

What about to issue a global error or just keep the s_initialized = 1?

[Hadatko]

s_initialized to one seems good. And thanks for point me to missing call function

[Hadatko]

Should be fine now. Please recheck.

[MichalPrincNXP]

additional comments:
a. what about renaming void erpc_transport_rpmsg_lite_tty_rtos_deinit(void) setup function to void erpc_transport_rpmsg_lite_tty_rtos_**remote_**deinit(void) - for RPMSG lite tty rtos transport we have just implementation for remote
b. to behave consistently, other rpmsg_lite - based transport layers and setup functions should be updated accordingly (deinitialization provided) . Will you be able to do so?
c. how about copyright update?

[Hadatko]

a. Well it depends. rpmsg denit function looks common for master and remote. So for other eRPC RPMSG transport layers can be created also deinit functions which will be common for both master/remote. So in this context it make sense to keep it this way.
Or we can create remote/master deinit functions always which will call static(private) common deinit function
b. Actually i can't right now. I would like to keep this pull request simple. For case which is bothering us.
c. Am i responsible for copyright update? If yes i will update it accordingly.

[MichalPrincNXP]

Thank you, Dusan.