I think you understand the implications pretty well.
Your options in this scenario are:
a) to embed just the bearer token and re-release the plugin in the event that you need to negotiate a new bearer token
b) to embed the consumer key and secret and re-release the plugin in the event that those keys need to be reset
c) require your end users to provide either their own bearer token or their own consumer key and secret
Option C has the least amount of risk, but the greatest burden on end users. It also means your app has no real identity of its own to Twitter.
Option B is probably the least secure option. You would need to reset your key and secret if the key were compromised and/or used for abusive activities. This option would allow you to still leverage user-based authentication and provide write operations if necessary. User-based auth is key to a consistent, predictable rate limiting scenario.
Option C is a middle ground. The largest risk is that your rate limits would be exhausted by someone using your bearer token, and requesting public data in your application’s name.