Avoid importing core Fabric as a library in Go implementation

[bestbeforetoday]

github.com/hyperledger/fabric is not intended to be consumed as a library. Doing so has the following problems:

• Risks breakage as Fabric implementation code may change at any time.
• Pulls in a huge number of largely unnecessary indirect dependencies.
• Causes compatibility issues due to ties to Fabric version, and its dependencies and their versions.

The primary reason Fabric is being used as a library seems to be for the protocol buffer utilities within Fabric. Unlike the utilities within Fabric, the protocol buffer message formats are well defined (if complicated) and versioned as public API. The protobuf message construction and manipulation required by the admin API as actually not too difficult and should remain stable.

A good alternative to importing Fabric internals might be to:

1. Include code in this admin API implementation to build and manipulate protocol buffer messages.
2. Where there is significant commonality between the code implemented in within this API, Fabric itself, and possibly other packages, extract those common pieces of code to a library module (such as hyperledger/fabric-lib-go) and make use of is in all relevant packages.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[SamYuan1990]

@bestbeforetoday , do you have any idea as a major dependency for now is bccsp.
do you think we create a new repo with bccsp?